I. James Kempf: Possible interoperability test - goal to complete design by late summer - first draft due in July - go to IESG in August/September timeframe - interoperability test in October - vendors want to implement it - implementations need to be ready in time - volunteers needed to set up a venue, testbed, etc. - volunteer needed for required/optional features checklist II. James: PS Draft Issue #2 : Include Nonwireless Networks There could be non-wireless access point or wireless access point Issue #5 : What does "network based" mean Issue #6 Global Mobility Management Discussion assumes a particular architecture III. James: REQ Draft Issue #1 Remove or Move Gap Analysis Move Section 3 to appendix , remove :"Gap Analysis" Keep "Gap Analysis" Henrik: "it's good, but incomplete" Gerardo: "I agree with James, to avoid lots of comments and time consumtion" Keep in the appendix Issue #11: document assumes an architecture Add a solution in Section 1 that describes the NETLMM Issue #12: Handover Performance Requirement is Vague Add some words Issue #13: Handover Signaling Volume Reduction Requirements is vague Resolution: clarify that the requirement to reduce messages Issue #14 Location Privacy requirement is a trivial consequence of LMM Resolution: changing this requirement to be not changing the IP address and use location privacy as one motivation Issue #15 Requirements or design Goals Kent: All requirements are design goals? There will be no difference between design goal and requirements. Issue #16 Add backward compatibility/reuse requirement Backward compatibilty is not a issue, Gerado: evaluate this, Pro and Con Henrik: Add in the resolution, much better statement than backward compatibility. Considering existing solutions in evaluation ... to replace requirement of re-using existing solutions. Discuss on the list Issue #20 Section 5 need better motivation Resolution: Remove section 5 from document James: Next Step Plans for PS and REQ - Update drafts with accepted issues after IETF - Start 2 week WG last call on or about Apr. 1st. - Line up some solicited reviews from people knowledgeable in mobile networking - Conclude WG last call and WG discussion of solicited reviews around end of April - Submit to IESG around 1/5 IV. Christian Vogt: Threats draft on MN-AR interface - New terminology needed (based on comments rec'd) - MN authentication, MN identifier, Data origin verification, data origin identifier, locator all defined - problem - spoofed data-origin ID and roaming at a victim's cost. Data-origin verification could prevent this, but only helpful in MN->CN direction. May need firewall on the MAP to prevent this. - problem - impersonation of MN during DNA. Impersonator mimics the victim - requires attacker to use the same IP address as victim. Limitation is that impersonator cannot forward packets to the MN. Differnet from MIPv6 scenarion, and not as severe. - problem - impersonating during DNA. Limitation is that attacker must redirect packets to itself. - problem - rogue AR acts as man in the middle. May eavesdrop the packets, modify them, forward on path outside NETLMM. Limitation is that return packets go thru NETLMM. - problem - vulnerabilities of IPv6 ND/DNA - problem - MN identifier associated w/ IP address. Attacker can track victim's IP address. Could send NS for victim and address resolution or DAD. Do ARs forward ND signalling to other links for DAD? - problem - location privacy. 2: Attacker btw AR and MAP. Most effective if attacker is close to MAP. Can be prevented by encryption. 3: Ip address tells victim is inside NETLMM. Limitation - NETLMM prefix not precise. - mailing list comments: - implicit data origin identifiers may not show up in packets (Julien) - data origin ID can be MN-MAP security context - draft does not mention flooding of MN's IP address - more dangerous for existing IP address - location privacy when attacker on access link Microphone comments: Greg Daley: if the person who signs the NS/RS uses the same SEND private key there is no problem. Is this too high a bar for NETLMM? Kent Leung: MN<->AR interface and AR<->MAP need to be considered. Need to address AR<->MAP security. Can take care of this in protocol design draft. Hesahm Soliman: are you assuming threats on data traffic, and why is this particular to NETLMM? If signaling is done properly there is no threat. Hesham: do you assume ingress filtering/SEND? There are a number of assumptions made. Will clarify with design team. Suresh Krishnan: how will ingress filtering work? Needs to be documented. Vidya Narayanan: ingress filtering is not particular to mobility. Authentication issue - somehow the MN knows the AR is authenticated. Need a BCP on what should be done. Vidya: MAP-to-AR interface is well understood; can you just run IPSec? James: Title is misleading - will change to reflect the context. Pete McCann: quite likely there will be EAP and 4-way handshake at link layer. Kent Leung: need to focus on MN<->AR interface. NETLMM is different from IP routing; need focus to understand new threats. Alex Petrescu: Is the design team working on the MN<->AR interface? No - only on AR<->MAP interface Vidya: needs to be a motivation section. Chairs: consensus call - Should draft-kempf-netlmm-threats be made only wg item in order to satisfy the wg foal of a threats draft for MN<->AR interface of NETLMM? Unanimous consensus. Need to confirm on the list V. Kent Leung: Design team update - Goal: Meet the requirements specified in draft-req. Identify components/functionalities of base NETLMM protocol Base NETLMM oslution draft originates by either:selecting or from scratch - timeline: DT concensus by May choose contributed I-D or create a new draft as base document write up in June submit base NETLMM solution draft before ietf 66TH meeting - AR-MAP end to end mapping, - Components: MN identifier Dynamic MAP allocation message types for location update between AR and MAP Message transport (control plane) Security between AR and MAP Address assignment for MN Support for any ip version host data plane transport(tunnel, mpls) ar-map reachability detection ar handover(including release ) - Out of scope: MN-AR interface inter-map handover fast handover hierarchical MAP - Status: Deliberation on the topcis continuing Need to write up summaries of topic conclusions MN-AR interface sync up needed Makesome progress in face-to face meetings Protocol has not been decided yet. Microphone comments: Hesham: MAP term can be confusing Kent: MAP has MIP function inside. Hesham: it's changing mn-ar interface. put it into the requirement. changing behaivour in the host, Kent: late presentation in the mn. Alex: Tunneling has been decided between AR and MAP, address assignment Status between AR and MAP, Kent: tunneling has not yet be decided, transport layer , bear transport, Data address assignment statatus based , could be DHCP Vidya: Disappointed by changing host, suffering for mobile node, netlmm domain has two MAPs in one domain, confused Kent: Each MAP serving prefix, mobile can anchor, Vidya: MN attachment, could be 3gpp, 3gpp2 interface, Kent: some layer 2 trigger, Henrik: return back Hesham question, netlmm client in the mobile node, James: We have not yet talk about MN-AR interface, focus on AR-MAP protocol, please wait. [?]: Multiple MAP can serve same prefix Kent: MAP redundancy, I am not sure whether it is in the scope [?]: Packet arrive map, ttl, same ip subnet Kent: We have not addressed that yet, three hops, just doing tunnel or ttl [Junghoon Jee] Question about time line, May is possible. There is a mention about "performance" in the goal. However, fast handover is out of scope. Thus, I am making clarifying question. Is the performance enhancement is in-scope or out-of-scope? Also, what's the time line of the DT? Kent: it should not be outside the scope. James: We already mentioned that, next ietf meeting. Alex: Curious question, some trigger in mobility, is that DNA, or DHCP? Kent: trigger is TBD, API trigger Vidya: small comment: netlmm and mip has same concern about ttl. SCTP and UDP are mobilty header? Fast handover is not considered, AR-AR tunnel will be goal here? yes. [?]: IPv4 is out scope, [?] two way to support IPv4, 1) access network, 2) IPv6 access network with IPv4 address actually last hop, backbone network is netlmm, Kent: transport ipv4 packet in NETLMM is possible VI. Julien Laganier: host address interface of NETLMM draft-laganier-netlmm-mn-ar-if-00.txt based on draft-wood-netlmm-emp-base-00 - Approach: chosen a starwman netlmm protocol - ARs advertise same off-link subnet prefix - prefix is used for stateless autoconfiguration - MN sends all packets to AR - use DNA and SEND procedures - quick failove rto new AR - secure detection of MN handover - use a single public key to generate all CGAs - Remaining issue: - SEND is acceptable - Chose as default AR the one sending RA - Do we use a single Ar link local address. Microphone comments: James: DNA, Layer 2 protocol talk with NETLMM protocol. Greg: exisiting multicast neigh discovery, it's time to talk with DNA. James: AR listen to all multicast address, David: RA subnet off link, application can know the differences, correlation with TTL, Greg: We never advertise prefix offlink, rfc 2461 ND. Vidya: Goal DNA is used? James: example how layer 2 supported, it is just a example how many people read the drafts: pretty good WG CALL on MN-AR interface Draft: sould draft become the only wg to satisfy the wg goal of a draft? Yes (many), No (1) Need to confirm on list. is there anybody IP version netlmm air interface? People are making argument: layer 2 control mobile node what to do, where to go? Vidya: 802.11i, I can choose trust IP layer,. Alex: information /experiement? James: Information James: A couple of questions in the list, discuss in the list. VII. Conclusion James: Thank you very much , run whole time. James: If you are interested in interoperation test, please come to me.