Minutes of: Mobility for IPv6 (mip6) WG At: IETF65 March 20, 2006 (Dallas) Chairs: Basavaraj Patil , Gopal Dommety Credit for these minutes: 1. Victor Fajardo (vfajardo at tari dot toshiba dot com 2. Timothy Kniveton for being the Jabber scribe (tj at kniveton dot com) Jabber logs at: http://www.ietf.org/meetings/ietf-logs/mip6/2006-03-20.html #################################################### I. Chairs statements: 1. Whats published - RFC 4238 - RFC 4285 2. Whats in the editors Queue - mip6-firewall - mip6-mipv6-mib - standards - mip6-percfgkbm - standards 3. Whats in IEST Evaluation - mip6-bootstrap-ps (info) - mip6-mipext-adavpi 4. IESG Eval - mip6-ikev2-ipsec 5. WG LC on mip6-cn-ipsec Comments: - HMAC-SHA1 in RFC4285 is 128-bit, why 128 and not 160 ? To be clarified by the authors. - HA reliability issue now has a design team a. problem document b. scope c. solution II. Presentations: 1. draft-ietf-mip6-v4traversal-01.txt (Hesham Soliman) - joint working group item with NEMO - CoA address independence, bind IPv4 to IPv6 and vice versa - NAT traversal - 5 issues outstanding - No discussion on the mip6 alias Issue updates: a. Issue 58: Proxy ARP in HA b. Issue 62: Editorials c. Issue 64: Sending BU and BA in UDP tunnels d. Issue 63: Prefering IPv6 CoA when both v4 and v6 are available Outstanding: a. Issue 60 ligthweight keepalives Overview: - netbinding on 110 seconds w/c is cumbersome - ping like keep alive is needed - current keep alives relies on BU in the absence of traffic - need ligthweight version for small mobile devices - create ping-like mechanisms over UDP Comments: a. Neutral - NAT Binding alive on other working group (BEHAVE WG - NAT behavior), can be inline with that work b. Pro - because theres lifetime in the BU, not same as keep alive - you must use the same UDP port so maybe not applicable to - expensive encryption - use only for keeping NAT bindings c. Against - do not think this is expensive - how about a lite BU ? - ecnryption may not be that expensive (Charles) if keep alives are very infrequent - maybe unecessary since other traffic can be used for keeping NAT binding, counter=for interoperability b. Issue 71: Use of the CoA option Overview: - use of CoA option requires the use of the HoA in the source address filed - This violates the format in RFC3775 Comments: a. Against - Second bullet is wrong - there is no violation b. Pro - It is a violation since text on 3775 simply says "how to send BU" - Dynamic detection of NAT in the HAs domain Overview: - current draft assumes that the HA is configured with presence of NAT in its domain - draft handles dynamic detection of the NA in the MN's domain - UNRESOLVED Comments: a. Pro - super set scenario for flexibility - could be an extension if there is a strong need - more configuration makes it harder - not as costly b. Againts - no need for dynamic detection as a consensus - more complexity 2. draft-ietf-mip6-ikev2-ipsec, 2401bis - Update (Vijay Devarapalli) Overview: - Minor changes to address Jari Arkko's comments - Remove reference to EAP-ONLY-AUTHENTICATION Notificatin payload - should be pursued separately - The K-bit - do we still need the K-bit if we have MOBIKE ? - at least move it to separate section - discussion in the ML: - IKE SA is delete, associated IPsec SA are also delete, so updating IKE SA is important - does not make sense to use MIPv6 and MOBIKE at the same time - k-bit is easier in IKEv2 than IKEv1 Comments: - cleanup k-bit issue (from Jari) - maybe out of scope ? - cannot say deprecate this flag in another doc, maybe say set or not but cannot say deprecate - no consensus to remove k-bit - make a statement regarding "if you use MOBIKE then dont use MIPv6". We need to be clear about it since there will be interoperability - what does mip6 want ? (jari) - we should do technical comparison before consensus a. Pro: - its fine to update 3775 because thats what we do - dont need to specify simulteneously use MOBIKE and MIPv6 because it's just an opinion and you can make it work maybe information text somewhere b. Againts: - keep k-bit but clarify operations, not clear cause you need to know how to implement it - IPsec Selector Granularity - Cases - Fine grained selectors are supported - tunnel mode SA for HoTi - Protocol level selectors are supported - Protocol selectors not available 3. draft-ietf-mip6-aaa-ha-goals-01 (Gerardo Giaretta) Overview: - Draft is fully reviewed - both split and integrated has been reviewed - has been updated in the latest version - Critical Portion: - G1.4 - AAA-HA interface SHOULD provide confidentiality since it may be used to transfer keying material - shared key generated during EAP authentication - Unsure Porition: - G2.2 - HA should be able to query the AAH server to verfy MIPv6 service authorizaiton Comments: - Should'nt require solutions in this group Reply from Author: - Intent is to just list all the goals - G2.5 - HA MUST BE ABLE TO REQUEST THE aaaH server an extension of the auth lifetime granted to the MN - G2.3 - Comments: - AAAH server MAY enforce explicit operational limitations and authorization - Are you asking a doc fulfills the goals has to contain this spec ? maybe multiple docs - ansr: yes. - What is the authorization protocol for use in this goal ? ansr: same as diameter - you can extend auth lifetime. Don't need to define new protocols since this is just a set of goals - Suggest remove 2.3 - difficult to do this in MIPv6, maybe use of this is logging that can be sent to HA but maybe not possible in MIPv6 - What is the relationship with the EAP-EMSK ? needs to be discussed in EAP and followed by MIPv6 - John: what are the really things that you really need since DIME is working on a app for this - Avi: issue with the work enforce - Main issues: - List requirements for AAA-HA interface - complete for split scenario - integrated scenario implies some MIPv6 attributes exchange from AAA to NAS - Should we broaden scope of the draft to encompass all AAA req for MIPv6 ? Comments: - Intention: Get all AAA requirements - When is this avaialbe ? (john) - ansr: broaden scope first (raj) maybe next ietf but need more feedback 4. draft-ietf-mip6-bootstrapping-split-02 (Gerardo Giaretta) Overview: - WGLC last Dec - New ID available after WGLC - 2 open technical issues a. Use-ASSIGNED_HoA attribute - specifies a new IKEv2 notify message type in case the MN tries to perform HoA auto-conf but it is not allowed - proopsal during WGLC: the HA may raise b. DNS Update - some concerns: mobile should update only if trusted scalability issue if each MN has to established SA with the DNS - no consensus to make the changes - DNS expert review requested c. MIP6_HOME_PREFIX attribute - draft specified attribute configuration in order to send Home prefix to the MN - no consensus - IKEv2/IPsec expert review requested Comments: - Do we want to ask expert if we want to have more prefixes ? ansr: try to get some consensus in the ML on what to ask experts. - Configuraiton stuff in IKEv2 is not designed to do this ? ansr: thats why we ask experts for this - Next steps - authors request WG chairs for expert review - if more changes then new WGLC 5. Report on MIP6 operation with IKEv1 Interoperability test from TAHI (Shinta Sugimoto) Overview: - Interoperability testing in IKEv1 and MIPv6 - Scenarios - K-bit = 0, results are in slides in the example message sequence - K-bit = 1, results are in slides in the example message sequence - Summary - rekeying in IPsec can be performed independely from MIPV6 registration - same with ISAKMP SA. However, ISAKMP SA sholud be closed when the MN changes its attachement 6. draft-sugimoto-mip6-homelan-access-00.txt (Shinta Sugimoto) Overview: - Seamless and secure access to home network - mip6 may fit well in this scenario, mip6 is assured to be connected to homelink - may rely on link-local communication to realize zero-conf - rfc3775 does not allow HA forwarding link-local traffic so propsed extension a. S flag - request link local home address, see slides for clarification on use of this flag b. link local multicast address option - allow MN to request for bypassing particular HA c. Alternate interafce ID option, valid only when S flag is set in the BU message d. security considerations: exposure of net internals to third party, off-path eavsdropping 7. draft-dupont-ikev2-haassign-01.txt (Francis Dupont) Overview: - missing features for IKEv2 based solution - strong properties for care-of address - home agent assignment(==choice controlled by the home side): this document - security - basically secure (cant get Ss with a fake home agent) - default defense for DoS agains the hHA (stateless cookie) - defense for Dos against the mobile node Comments: - unknown from the chairs on how to proceed ? needs more discussion in the ML 8. draft-devarapalli-mip6-authprotocol-bootstrap (Vijay Devarapalli) Overview: - why ? current bootstrapping focus on IKEv2 - Boostrapping HA - Home agent configuration - SA setup - RC4285 is an alternative to IPsec (and IKEv2 but does not provide all the feateurs) - Reachability, no new mechanism, DNS update Comments: - Questions on why we need another bootstrapping protocol ? need to have further discussion on justifying the work 10. next steps for the WG Overview: - mip6 boostrapping, solution for split and integrated - v4/v6 tranversal - progress the location privacy for publication as information RFC - increase scope of doc AAA HA goals. doc to be last called in the WG - split the base protocol spec (mip6), i.e. sep route discovery etc. Comments: - give it time to have some implementation experience (question) - a few mistakes are there so we may want to take on the work also since there are dependencies (chair) - should be one document since its hard to keep track of the pieces (comment) 11. draft-chowdhury-mip6-radius-00.txt (Kuntal Chowdhury) Overview: - Bootstrap scenario for MIPv6 with RADIUS - covers the bootstrapping goals doc - split scenario - HA as a RADIUS client - RADIUS server may also instruct the HA to perform DNS update for the MN - integrated scenario - see goals - RADIUS attributes Comments: - should this work be in DIME or RADEXT ? - verify the neighbor case - add a mobile network prefix attribute - next steps, work in the goals people, maybe for the RADEXT group work