Minutes based on notes from Jouni Korhonen 15:30 RFC 3775bis Wrap-Up ................................................. 15 min Charlie Perkins http://tools.ietf.org/html/draft-ietf-mext-rfc3775bis-06 - missing paragraph. Added new text to 9.5.1 - Julien: SHOULD in here? - Charlie: discuss it. - Julien: if implementing, should refers to sending to error code or...? - Charlie: if there is a good reason mobile can choose not to send the error, like when HA and MN has somehow agreed differently. - Julien: still confused. Discuss in mailing list. - Marcello: Julien is asking how you qualify SHOULD? - Charlie: should respond unless the receiving node has some additional information.. - Julien: on MN "SHOULD NOT" vs "MUST NOT" in case the MN does not understand why its BU got rejected and thinks SHOULD NOT is OK. 15:45 NEMO Prefix Delegation Wrap-Up ...................................... 15 min Carlos J. Bernardos http://tools.ietf.org/html/draft-ietf-mext-nemo-pd-05 - WGLC went through Match 2010, comments adressed - when MR is not at home, it is assumed to have DHCPv6 Relay Agent function. - Avoids updating rfc3633 - Avoid sending DHSCP messages with LL addresses, instead use CoA and HAA - only use MIP6 inherent IPsec to authenticate DHCPv6PD signaling. - Alex: happy to see the msg exchange in slide 5 - Alex: would it be possible send DHCPv6PD messaged without RH2 or HoA dst opt? - Carlos: DHCPv6 does not allow that immediately. You need unicast option first. - Alex: ...Relay in HA? - Carlos: keeping delegated prefixes and those used for binding in the HA in sync is not trivial. Considered hard enough not to allow Relay in HA. - Combes: ... - Carlos: getting delegated prefix info to MIP6 module hard - Combes: continues on the same topic.. - Julien: this was already discussed in ML. 16:00 Lone Home Binding ................................................... 15 min Julien Laganier http://tools.ietf.org/html/draft-laganier-mext-lone-home-binding-00 - Julien: issue worth solving? Is there a real issue? - Julien: this is a missing piece in 3GPP. - Ruyji: is the HA supports MCoA does it create two bindings? Is it more a problem to find a HA that supports MCoA? - Julien: If not.. - Raj: The intent is to maintain binding when returning home? - Julien: no, need to find out whether the HA supports MCoA before actually doing so. - Sri: When do you activate this? - Julien: Whenever you do initial attach to a home link and don't know what HA supports. Does not make sense when initial attach on foreign link. - Sri; ... - Alex: Wants to understand the prob better.. is the prob that only one link can be used when MCOA fails? - Julien: Yes. MN wants to use both but ends up only having foreign link usable. - Alex: When to do this? - Julien: after the initial attach, check on what level of functionality the HA supports. - Suresh: Agrees the problem is real. Go and ask this during bootstrapping. BU phase is too late. - Julien: Are you asking me to change bootstrapping? That is a hack to do that on it. - Suresh: Just one more option there. - Julien: Just fix for mip6 protocol. - Sri: on capability discovery.. nemo? - Julien: you could use this for nemo. just use nemo prefix mobility option and you'll learn whether the HA supports it. - Rajeev: this prob is general. one could use RAs. Deserves further discussion. - Kent: have you covered sequencing issue as well? MN and HA must be in sync about all binding and stuff. - Julien: if HA does not support MCoA no binding gets created and BAck with an error is is replied.. - Kent: need clarification on these here. 16:15 Router Advertisements for Routing between Moving Networks ........... 15 min Alexandru Petrescu http://tools.ietf.org/html/draft-petrescu-autoconf-ra-based-routing-00 - Sri: experimental or standards track? - Alex: don't know. maybe informational. - Sri: would reverse routing header have solved this (past work..) - Alex: in nested HA scenario yes.. 6:30 MEXT WG Rechartering Discussion ..................................... 40 min Marcelo Bagnulo, Julien Laganier - Marcello: past meeting talked what to do with alt sec for mip6. There has been energy work on it. not an easy decision. including changing a mature protocol.. How to frame this to charter. - Three possible options (after talking to AD): 1) recharter to make reqs doc 2) recharter to do alt sec solutions on experimental track 3) do nothing - Julien: likes option 3. 3GPP is completing whole MIP6 stuff for EPC. It is important to fix missing bits for that rather than making new stuff. To get ppl that believe in IPsec and those who not to work together for anything useful will doubtfully achieve success. - Charlie: does not agree. Wrong to say ppl has no energy to do this. There is evidence that IPsec has been the barrier not for adopting MIP6. - Marcello: in terms of what to do next? - Charlie: revision of 3775.. - Marcello: oprion 2? - Charlie: yes - Jari: asks for Charlie's relaxation option of security - Charlie: rely on security options operators have and the security properties there are. That are not necessarily standardized in IETF. - Julien: energy. Different thing to present than work actively on drafts etc - Combes: option 3. no reason to work on something.. no tech reason against IPsec. - Raj: statement that MIP6 is mature and perception of industry... bla bla own experience on implementing it is not a simple to implement. IPsec is the prob We believe MIP6 was for mobility not for complex implementation. Many other ways around. Interest & effort.. option 2 and see which protocols get adopted by indistry. - Rajeev; does not like multiple choices. - Marcello: so do ipsec - Rajeev: 3775/6 were 2003. option 1 makes no sense. respond what market needs are. option 2 but does not like experimental. - Jari: comments on options and doc status. multiple proposal if we start working on this. that is the concern. then we need to make the right choice. - marcello: if you make a new one then you got at least IPsec + something else. - Rajeev: do a spec and let industry decide. experimental is a misconception already.. IPsec continues to be there. do something new - Marcello: so option 2? - Jari: worried about whether there will be one or multiple proposal. then selecting between them becomes issue. - ... - Charlie speaks for solutions where security is not from IETF.. operators do their own. - Jari: already do taht in.. must implement ipsec but ppl are not mandated to use it really.. - Marcello: solution already on TLS. Charlie proposing yet different approach not doing security in IETF.. - Raj: ...expecting multiple solutions? - Marcello: yes.. selecting between them is another exercise then. - RAj: ... - Erik hears requirement to remove IPsec. For interop you need one mandatory to implement one security protocol. Otherwise we end up having multiple solutions that claim to comply to the "new" rfc but do not interop. - Raj: don't think we are saying it at this very point.. - Erik: .. - Raj: getting IPsec to interop is hard. - ... - Julien: IPsec for MIP6 has been implemented in Linux for example.. - Rajeev: How to respond for someone who wants to use MIP6 but not 3776.. one cannot say "use it or lose it". - Erik: confusing discussion. Two points: Is it the case that the existing mechanism has interoperability issues? Are they documented? The other thing is, you have to mandate one security mechanism otherwise there is no interoperability and we failed as a community. - Jari think we should develop a new thing. Agree with Erik that we cannot say that there is no security reqs. - Erik: The way a new alternative mechanism is introduced while guaranteeing interoperability is, you make the other mechanism available, and if it is successful at some point you make it mandatory along the initial one. After a long enough period of time you can think about removing the mandatory requirement on the original mechanism. This is how you insure interoperability. - Kent: option 3 is not ok based on the earlier agreements on the group. So we are left with options 1 & 2. - Jari stresses the importance of energy.. - Marcello: WG has long history of not reviewing/completing drafts. - Jari: .... (long monologue) eventually wants to see multiple solutions but not to charter them immediately. Definitely not option 1, maybe option 2. - Jari: poll the room for different options? - Option 1 got 2 hands Option 2 got lots of hands (clarification, first experimental, then select std one) Option 3.. some Rough consensus for option 2. 17:10 Implementation experiences and operational behavior of DSMIP6 using TLS based security ......................... 10 min Basavaraj Patil http://tools.ietf.org/html/draft-korhonen-mext-mip6-altsec-05 - Raj concludes the implementation was easier than IPsec one. - All traffic is UDP encapsulated, which simplifies NAT traversal a lot - Yuri: IPSec is not gone. Will vpn work on top of this? - Raj: Yes. - Alex: DNS stuff and the problem. That was not related to TLS? - Raj: .. - Sri: GSSA-API? have you considered that over TLS? - Raj: TLS selected for wide deployment & availability.. - Hannes: lots of auth & sec solutions. TLS selected because it existed also on platform we wanted... - Sri: Are you .... (Marcello stops discussion) - Erik: You are using UDP encap.. How about route optimization? - Raj: not is scope.. could be used without UDP encap when on v6 links.