Mobility EXTensions for IPv6 (MEXT) Minutes for IETF-71 meeting ==================================== Chairs: Julien Laganier Marcelo Bagnulo Braun Scribes: Gerardo Giaretta Sri Gundavelli Suresh Krishnan Sessions: WEDNESDAY, March 12, 2008 0900-1130 Morning Session I THURSDAY, March 13, 2008 0900-1130 Morning Session I Minutes: - Status of MEXT deliverables Chairs DSMIPv6: dealing with Pasi's comments. Still outstanding comments. Last changes can be done when the revision is done for IESG MCoA: new version after George's comments. New WGLC AAA goals: new ID needed. After that send to IESG RO for Personal Mobile Router: no WG draft yet. There is a possible candidate but comments and reviews must be needed RO for automobile: new draft accepted as WG item. Need more comments RO for aircraft: finished the WGLC but good shape and the group can start working on solutions PD for NEMO: ongoing discussion to be discussed today Solution for aircraft RO: work on solutions starts now RADIUS MIPv6: new version to be discussed today Analysis of use of MCoA: Monami6 document updated long time ago. No input for now. Input needed. It deals also with multiple HoAs Multiple Interfaces motivations and scenario: Monami6 document. Review needed. Situation similar of the previous document. Mobile IPv6 operation with firewalls: no WG item but output of a DT. To be discussed today MIB for NEMO: WGLC after IETF Flow/Binding Policy: draft by Hesham accepted as a WG item. Still waiting for the draft which will be available at the next IETF Flow Binding policy format: no WG item yet. Two drafts should be merged. Update of RFC 3775: several comments in the mailing list. A compilation of all proposed items to be discussed today. Home Agent reliability: authors say the document is ready. Most comments received were editorial. The document will be updated o Recharter items under discussion One item needs more discussion, which is the p2p home link model. - Home Link operation over p2p links draft-sarikaya-mext-homelink-prefix-delegation-00.txt Bechet Prefix Management issue when the p2p link is a home link CFG_REQUEST triggers DHCP signaling Francis, Julien and Gerardo: no protocol work. How the HA gets the prefixes is up to the deployment or the system architecture. Frank: p2p model implies that there is a prefix per MN while in the shared link there is an address per MN Tom Taylor: people need to work on the problem and expose better the problem to the WG - MIPv6 home link operation in various SDOs draft-devarapalli-mext-mipv6-home-link-00.txt Vijay Jouni presents the slides on behalf of Vijay. MIPv6 used in other SDOs with some links designated as home links. Booting up in a p2p link which is supposed to be the home link needs some considerations Hesham, Gerardo clarified that the home link detection is done comparing the IKEv2 prefix and RA prefix George: an informational document which explains how to do this without requiring new protocol work Hesham: OK with an Information document but no need for changes Julien clarified that there is a p2p link which handles the routing. There is no state at the HA, so the "HA" is just acting as AR and sends the downlink packets to the MN Gerardo: no need for service selection in the BU as there are already solutions in the p2p link negotiation George and Suresh: no need for protocol work, probably worth clarifying Gerardo: an informational document describing how IKEv2 MIP6_HOME_PREFIX is used to detect the home link. No specific Jouni: no protocol work. Ahmad: problem statement needs clarification. Raj: the scenario is not clear and should be discussed in the mailing list George: write a charter paragraph which describes what the problem is and discuss it in the mailing list Next Step: George proposal o MEXT Deliverables - Multiple Care-of Addresses Registration draft-ietf-monami6-multiplecoa-06.txt Ryuji Several comments after the WGLC on version 5 3 remaining issues. WGLC on version 7 after this IETF Sequence Number issue. Proposal: MN should manage the SN value for all bindings Enhanced RO: not clear if MCoA works with this. Additional review needed Simultaneous Home and Foreign attachment: HA intercepts all packets and decides to send the traffic directly to HoA on link or tunnel to CoA. MN sets the H bit in the BID option for the interface in the home link Julien: to get the L2 addresses, ND must be used and L2 headers should not be considered for this purpose Sri: how the packet is sent via the home link? Ryuji: MN sends traffic to the HA George: this is not modifying the proxy ND but some special treatment is needed Ryuji: MN is not defending the address on the home link Sri: take this offline to check SN issue is solved. Enhanced RO: review needed Simultaneous Home and Foreign attachment: text needed and then discuss on the list - Automotive Industry Requirements for NEMO Route Optimization draft-ietf-mext-nemo-ro-automotive-req-00 Roberto Baldessari RO scenarios Requirements - separability: switching to RO is subject to policy table to avoid unnecessary RO sessions - security: MNP ownership should be checked against off-path attackers. Requirement to be extended for better protection. Certificates can be used Marcelo, Hesham: saying there is a certificate assumes already a solution Julien: proof of ownership of the prefix may be a good wording Francis: authorization of prefix is better than proof of ownership - privacy protection. Exposing MNP must be limited to CE and nodes on the path MR-CE Julien: privacy is not the right term as HNP does not give information of privacy Marcelo: if you use a prefix to figure out how many times one is in a foreign link, you have a privacy issue Requirement will be rephrased - multihoming - efficient signaling. Text in the draft is outdated - switching HA. Considered in ISO CALM. RO should not prevent it from working Marcelo: is this related to multiple HoAs? Not clear. Needs to find out if it is different HoAs or not William: is this for reliability of the HA or for the RO? Marcelo: whatever RO solution it must be compatible with HA reliability solutions - NEMO Route Optimization Requirements for Operational Use in Aeronautics and Space Exploration Mobile Networks draft-ietf-mext-aero-reqs-01 Wesley Eddy Believed to be ready for WGLC Changed requirement on loss to also require NOT duplicting packets Biggest change in Security Requirement Old was IPsec MUST be usable New requirement is clearer. Hesham: why is it safe to assume trust relationship between MR and mobility anchor points topologically near to CNs? Alex: Was it considered RO neighbor correspondent nodes? It seems not desirable. Marcelo: the solution can work with both CN and a box nearby. The security requirements for this are stronger than the 3775 RO. No on-path attackers are accepted. Alex: this deserves further discussion on the list Fred: interactions between the global routing and RO. Global RO may not have a direct route. Can RO survive? One or two packets may be lost, one being the BU Wesley: BU may not go through but you can still use the HoA Marcelo: there is a scalability requirement to not cope with global routing Fred: need a couple of weeks to look at this Marcelo: we need to close this re document in the short term Alex: need to empahasize that session continuity is provided via RO Next Steps: document is in good shape. Comment on the next two weeks. A new version will be produced. - DHCPv6 Relay Agents and NEMO draft-dupont-mext-dhcrelay-00.txt Francis Dupont Francis thinks neither of them can get consensus and that is why we need a solution with relays. He Talks about the advantages of these Francis has implemented DHCP code twice and know that relays are small and straightforward. Putting relays at two ends is a nice way of encapsulating dhcp traffic. He thinks it is a nice way of getting consensus Julien points out that only one of the proposals uses DHCP Francis says the other one can use a DHCP message piggybacked on a BU/BA Julien does not see the point in optimizing PD. It happens rarely and not on critical path George mentions that the good thing about this proposal is that there is no need to do any protocol work. He thinks that the draft is unclear but can be fixed Sri wants to compare this to the Thubert/Droms draft Alex thinks the diff b/w this doc and the Thubert/Droms draft is the encapsulation of the DHCP packets. He is not sure it can work Francis is aware of someone who uses this. Alex agrees that it is worth exploring as a solution Behcet discussed this on monday at DHC Ralph mentioned that this requires standardization. Behcet posted 2 drafts on this issue and he seeks comments Julien wants to know about the security of this mechanism Francis mentions it is just like DHCP (no security). He mentions the DHCP auth option Alex mentions that multicast and anycast are hard to secure Francis mentions you can use IPsec Ryuji wants to know how to configure the DHCP server on the relay Francis mentions there is a list of servers configured on the relay You can use an anycast scope (all servers and relays>ll scope) Francis believes it is good to put a relay or a server on the HA Ryuji says that the main diff between the Thubert/Droms doc is if we put the relay on the MR. Maybe we can update the T/D doc. Fred Templin is working on colocating the relay and server the same node in autoconf Teco Boot agrees to update the T/D doc and then try to get consensus Sri wants to know what happens after the tunnel disappears. How does the DHCP relay work? Will the DHCP packets get routed to HA Behcet thinks that the tunnel vanishes after the MR returns home George wants to mention that once you deregister from the HA the prefixes obtained from DHCP are gone. Sri and George to discuss this later on the ML. Sri wants to couple the eventual solution to the mobility signaling Marcelo wants to know if the nemo pd draft can use the contents of this draft to fix these issues? Alex supports both the proposals. He thinks we are going too fast for the market and it is too early to choose. Hence we can take our time. Alex wants a list of solutions instead of just one. Marcelo wants to pick just one. Teco thinks that if the DHCP has to disappear with the tunnel, then the DHCP PD is not an option. Francis mentions the DHCP release message Jari confirms Marcelo's view that we can do only one solution. if we cannot decide we should do nothing. He wants to see some direction from wg Behcet agrees with Jari but the authors are not present. TJ (through Ryuji) wants to know why we cannot use dynamic dns for mobility? Francis thinks DHCP PD should be based on DHCPv6 Julien thinks PD entails state keeping in the DHCP server. there is no choice George mentions that DHCP-pd is used over lte, pmip and dsmip links Consensus for DHCPv6 prefix delegation - to be confirmed in the mailing list. Votes: 26 votes support for using DHCP based approah/ 2 votes support BU based approach - Guidelines for firewall vendors regarding MIPv6 traffic draft-krishnan-mip6-firewall-vendor-03 Guidelines for firewall administrators regarding MIPv6 traffic draft-krishnan-mip6-firewall-admin-03 All - 15 min Nobody has read them Marcelo gives the room 10 minutes to read and comment Henrik wants to reduce timeout for the state from 420 sec to something more reasonable Jari thinks that the document is talking about generic IPv6 issues as well. He wants to scope down the document and remove these things. Marcelo and Sri want one document (not -admin and -vendor) Suresh disagrees with them. He thinks the audience for the two documents is different and hence they should be separate. Henrik agrees with Suresh. It makes the documents clear and concise. He thinks vendors like concise documents like the firewall-vendor draft. Sri thinks it can be a section inside the combined document. Henrik wants a smaller document focussed at SOHO router vendors Jari thinks the merge/split document is not the right discussions. He wants to discuss next steps Marcelo wants to address Jari's comments to pull out general ipv6 stuff from doc and then ask for adoption - RADIUS Mobile IPv6 Support draft-ietf-mip6-radius-04.txt Kuntal Radius MIP6 support skipped since there is nobody to present - RFC 3775 update Chairs - 15 min DHAAD removal issue Jari wants to see if the functionality has been implemented and used if it is not, it is fine to remove Gerardo thinks that we are removing something that has been outdated by other work (e.g. bootstrapping work) Jari thinks we need to also judge future interest Alex knows about 2 implementations of dhaad Alex thinks the scenarios for bootstrapping are different than those for dhaad He wants to know if diameter has outdated radius, has ikev2 outdated ikev2 Gerardo clarifies that he did not mean bootstrap work was more advanced but it is more adopted and used Charlie wants this discussion to be done on ml Sri has an implementation and does not want to remove George agrees with sri to keep it but he wants the security implications to be clarified Jean-Michel mentiones IKEv1 is obsoleted by IKEv2 Alex does not care and thinks people will still use IKEv1 Jari thinks there is support to keep in the doc Marcelo wants to have some diff text about the security issues Sri wants to leverage existing text Alex mentions there is already language in rfc3775 Jean-Michel sent some text to ML and Alex agrees with it BA/Berr sent by HA Alex and Ryuji think HAs can already send BRR/Berr Jari thinks that binding errors can be sent by both HAs and CNs. He also thinks that this was the intent and the text in RFC3775 is unclear about the term CN Jari and Alex need to agree about BRRs Deng Hui needs clarification since he faced the problem with HA switch messages Returning home Sri agrees to switch SHOULD to MUST George wants to keep the SHOULD. He wants the capability to decide when to send Sri and Jari mention it is a MUST when the node wants to start using its home address The chairs will accept new issues for 3 months and then try to close them Henrik wants all the issues to be tracked in the issue tracker o New Charter Items - Binding Revocation for IP Mobility Ahmad Muhanna presented by Sri Jari has reviewd the document and is fairly in a solid shape. However, the document is written with more focus on the usecases. Authors must publish the new document and fix it Sri agrees that the document needs to be restructured, says that the authors planned to define the mechanism in a generic way and list some examples at the end - Generic Notification Message for Mobile IPv6 Sri Henrik asks why this draft is not listing the most obvious example that is Revocation use case in the examples for this mechanism and why there is a seperate draft for Revocation Sri answers that we dont specify receiver action in generic notification mechanism Revocation requires specification on the event peer and requires more focus. Sri mentions that also, notification mechanism provides a generic container for all events. We should not use up the MH number space for every event and so we need to define a number space for one MH type. Sri mentions that some people suggested that the revocation mechanism should make use of the number space from the notification draft Gerardo says that then it is ok if Revocation uses one of the sub-type - Virtual Home Link configuration for Mobile IPv6 Sri Hesham thinks anycast is no different in v6 than in v4. He thinks the only difference is a reserved prefix in v6 for link specific anycast Ryuji mentions that rfc3775 assumes that prefix is a /64 Vijay thinks that there is a specific prefix reserved for DHAAD anycast Suresh mentions that it is a reserved interface identifier and not a prefix Discussion to continue on list Acee wants to know if this doc will be informational Sri thinks so - Extend DSMIPv6 Home Network Support George Domagoj wants to know about the usage scenarios. e.g. v4 HoA as the CoA for the v6 HoA o Other topics - Alt-CoA check draft-arkko-mext-rfc3775-altcoa-check-01.txt Jari Hesham is neutral to this change it is good because this can be enabled and disabled on the receiver based on the info in the BU Jari mentions that text changes needed to FMIP and have been made Jari mentions fmip has a more specific rule for alt-coa handling FMIP Ryuji mentions that MCOA does not use Alt-CoA and so there is no conflict b/w this proposal and monami6 work but Jari thinks the problem still exists Do we trust the node to just check one of the addresses in the packet? He has not thought much about this yet Sri wants to know if there is a configuration knob Jari mentions that it is tuned on by default but can be turned off Ryuji wants to mention whether the src address or alt-coa will be used by the HA Christian wants some kind of negotiation between the HA and the MN to see if it is turned on Jari does not like to have negotiation George mentions there is no point negotiating with a potential attacker Alex wants more granularity (per HoA basis) Jari wants to take some time to see if we can accomodate the mcoa stuff in this doc within say 3 months - Residual threat analysis draft-haddad-mext-mip6-residual-threats-01.txt Geroge George solicits more inputs on threats Francis thinks attacks are very easy if we are attached to multiple links (at least one of the valid CoAs is used) Julien wants to know how CGA helps Suresh mentions that it prevents flooding a specific address but not flooding a link Jean-Michel wants to know if the work takes into account the work done in sava/savi Marcelo wants to document the threats first and then decide what to do with them later. The scope of the work is threats that are SPECIFIC to mipv6 Hesham wants to know about ingress filtering stats George mentions that we can create optional mechanisms that only paranoid people turn on Christian Vogt mentions 25% of internet addresses can be spoofed and savi wg is more limited only source address validation on local link Francis mentions that there are attacks that do not use source addresses and they cannot be covered by ingress filtering Marcelo wants to cover all cases not just CoA address issues Jari wants to focus the document without making huge claims Jari mentions that the relationship between the HA and Mn is traceable. Anonymous HAs would be a good idea but they do not exist George mentions that the device can be traced, but not the user e.g. SIM Jari mentions that a SIM can be traced to a user George says not in Europe Jean-Michel says that is not true in France George says we will not do this for France. (laughter) Jari mentions that this work might have an effect on MCOA and hence we need to analyze the effects - Simultaneous Mobility Problem Statement draft-wong-mext-simultaneous-ps-00.txt D. Wong Hesham wants to know whether we are documenting or trying to solve Francis mentions that rh + hao as suggested is worse than tunneling and is a security nightmare Suresh mentions that he and Wassim had a draft 4 years ago that dealt with the same issue and there was no interest in solving it. It was called Binding Update Backhauling.