IP Routing for Wireless/Mobile Hosts WG (mobileip) Tuesday, March 19 at 0900-1130 =============================== CHAIR: Basavaraj Patil, Phil Roberts Minute Taker: George Tsirtsis 1. Agenda Bashing, Basavaraj Document status Discussion about FMIPv4/v6. There is no progress at the moment. There was some interoperability test for FMIPv6 2. Registration Revocation in MobileIP The speaker solicits interest for the draft. Some private discussion has taken place but not much in the public domain. Show of hands for support of this work was requested. Someone from 3GPP2 stated that this is one way of doing this but there are other ways too. A few people showed interest so the work will go ahead 3. Connectathlon Update, Samita -Mobile Ipv6 draft version 15. 10 participants No major problems were reported 3 implementations had support for authentication sub-option, no other security mechanism was tested Two Questions: How useful is the "refresh" field in BAck? Should this be dropped? Charlie: Suggest we make it an option since this is not always needed -FMIPv6 Handoff 2 implementations A number of issues will be sent to the mailing list by Alper Y. -MIPv4 6 implementations RFC3024 was implementated ut all missed the LPAS feature No major issues 4. Mobile IPv6 Discussion Phil R talked about MIPv6 security progress the last few months 4.1 MIPv6 Design Team - Jari Draft was sent to mailing list a couple of days ago -Pre16.txt is the actual spec, pre16.pdf describes the changes Draft version 17 will also be needed. Main changes are in section 4.4 and 5.1 There are now 5 messages needed but only 1.5 RTTs, 2 messages sent via two paths at the same time Hesham: is it still worth making BUAck mandatory? Jari: the issue will be taken into account Charlie: We need to specify how long does the MN need to wait for the messages coming back Francis: Verified/non-verified terminology should be used Charlie: Mobility Header should be called Next Header Type Erik: This may confuse because this is a terminal header for MIPv6. There is need for some text in the spec to clarify Vijay: Shouldn't the Home Address in BU is a parameter rather than fixed? Jari: maybe this is a good idea, take it off-line Jari: Discussion about retransmission strategies is needed Discussion about the nature of the security association between MN and CN. Francis: You need R-bit in the BU Erik & others: this is taken out in earlier spec Jari: Take it offline Hesham: To protect the CN from DoS attacks the CN runs in stateless mode. Isn't the MN vulnerable to the same attacks? The CN could be the bad guy Jari: Someone needs to remember something and the MN benefiots mostly from this Hesham: Yes but it is still a problem Erik: So what is the concern? Hesham: The CN can create state in the MN just by sending Binding Requests Jari: Very little you can do about this Erik: MNs could have intelligence to only do RO with CNs that make sense to do so Hesham: Some text about this would be useful. James: Have you done a stady on what the impact would be to create statefull CNs and stateless MNs as opposed to the other way around?? Someone: this is also allowed by the specs Charlie: Draft 16 is interim.no one should implement this. Draft 17 will be the real one Jari and Chairs: YES! Charlie: Are we really considering using IPSEC as the sole MN-CN BU auth mechanism? This is too heavy! Hesham: This maybe used instead of HoA test Jari: Maybe 4.2 Currently Open Issues in MIPv6 Base Spec Erik N for the Design Team -Many Editorial Issues -Max Binding Lifetimes should be defined (5min?) -State Tables for CN, MN -Better Terminology for "RR Procedure" COT/COTI/HOT/HOTI -Better names for message types Charlie: Need to make sure we allow static security configuration for special cases Thomas: Are you asking for the spec to say that the Bus can be secured by mechanisms outside this doc? Charlie: we should say which bytes MUST be protected but the way this is done should not be restricted. In the IETF we define ONE way of securing the Bus but this should not be presented as the only one. Someone: Agrees with Charlie More Open Issues: -Bit Method to prevent bidding down attacks Malinen: wants this method to be in a different RFC. There could be other methods of expressing the fact that you do not want to do RR. Lets get a few ways and pick one. Phil: This is a complex issue, There are arguments that this is needed in base spec Pekka H: when we do Security engineering as opposed to normal protocol specification we specify that we MUST NOT do something. This has to be in base spec. It is not possibly to put in different document something that prevents something in the Base spec from happening. Thomas: the Base spec needs to have code here so that all nodes supported otherwise it can never be used Bob H: Are you suggesting the bit will say do not do RR but will not say what to do instead. Isn't this an attack itself? Erik: Now all will do RR but when a new mechanism people will be able to use it. This is only for your own communication and does not affect others Bob H: Concerns about the idea to reserve bits in interface ID of the Ipv6 address space. Addresses are defined as global/local/unicast/mcast etc.This is a peculiar use of this and in the future we could have other ideas that need the same.This may not be a good path to take Malinen: There is need for this but the bit idea may not be the only one.Unclear at this stage Raj: Is it not possible to deprecate RR altogether in the future? Erik: You can not do that because it will have to be done in all nodes, all Internet Malinen: the same was done with going from MD5 to HMAC in MIPv4 Erik: Yes but that does not affect CNs! The IPv6 WG will discuss reserving bits for this in ther Ipv6 WG meeting in Thursday. We need to make the usage case in MIPv6 Issue: How and whether to authenticate the BA and BR Should we add a nonce in BU which will be returned by BA/BR? Is this enough? Vijay: For the BUAck you can use the same key you have for the BU. BR is different. Hesham: It is not different because the CN can only send a BR after a BU has been received Issue: Whether to authenticate to BM? The BM can be spoofed by off-path attackers, which would cause some more work but no ill effects Issue: Should HAO be used in the Home Registration or not? Issue: How to secure home registrations, use ESP or AH? Someone: If you use ESP how are you going to secure the CoA? Vijay: You need to repeate the CoA in the BU itself, can not rely on the source address of the packet Erik: Yes, that is right. Issue: Is it useful to have an SPI field in the packet It is not needed for RR but maybe could be added as an option by future mechanisms Charlie: We need to allow manual and other mechanisms but the SPI could be an option Issues will be sent to the mailing list for further discussion 5. LMM Requirements, Carl draft-ietf-mobileip-lmm-requirements-01.txt Suggestion to move on the requirements document to last call. Carl: Jari has one possibly new Security requirement James: We need one solution on this. Phil: Jari please post security requirements to the list. Also everyone check how the MIPv6 discussion affects this. 6. MIP/VPN Issues, Phil draft-adrangi-mobileip-nat-vpn-problem-stat-req-00.txt eFarid on VPN traversal for MIP Phil: Is this a problem the WG wants to solve? GeorgeT: The Work are needs to consider the larger picture i.e.: HA inside and outside of the firewall. Someone: This is definatelly an issue and needs to be resolved. Bob H: This is waist of WGs time. By the time this is really a problem you should be solving it with Ipv6 GeorgeT: This is also a problem for MIPv6 Someone: But then you do not have the NAT issue Phil: George should propose extended scope for the work the list maybe split between NAT and Firewall traversal. 7. NAT/NAPT Traversal, Henrik draft-ietf-mobileip-nat-traversal-00.txt Someone: There is at least one backwards compatibility issue Henrik: Yes we know about this and we can consider it. Phil: We will issue last call after the IETF 8. MIPv4/AAA Keys Open issues, Phil Phil: some issues seem have to been resolved. Only issue is re-authentication Charlie: all changes are in the last draft. Phil and Charlie agreed that the changes are small enough that no new last call will be needed.