MEXT – 28 July 2009 --------------------------------------------------------------------- MEXT meeting agenda - IETF75 TUESDAY, July 28, 2009 1520-1700 Afternoon Session II 1710-1810 Afternoon Session III --------------------------------------------------------------------- Meeting minutes based on notes taken by William Ivancic & George Tsirtsis. Slides are here: https://datatracker.ietf.org/meeting/75/materials.html 1. Blue sheets, scribe, agenda bashing Chairs - 5 min 2. Next steps with RFC3775bis Chairs - 5 min Charlie Perkins agrees with bullets - Will not re-discuss issues on which we already agree. - Will not add new issues - Sanity check - Editorials are welcome Document will go to last call. Patil – to mic. Really no new issues? Then do we redo RFC 3775 bis? Marcelo - No need to add new improvements. If something is really broken it will not go through IESG. 3. Use cases for flow bindings in the HA->MN direction Frank Xia - 20 min Behcet Presented for Frank Xia http://tools.ietf.org/id/draft-xia-mext-ha-init-flow-binding-00.txt Slides being presented. Slides are here: http://www3.ietf.org/proceedings/75/slides/mext-2.ppt Patil – Why is operator telling mobile node which interfaces to use? Mobile node maybe wants to control traffic and traffic. Today mobile node controls traffic. It is up to mobile node to do signaling. George – Seems unnecessary. Revocation appears reasonable. Regarding multiple interfaces, the mobile already knows information. Marcelo – Inter-Interface flow movement. HA has more information than mobile node so can provide better input than mobile node. Ryuji – question on load balancing. Maybe same use case as mobile-ip case. HA may know more information for load balancing. Patil and Marcelo – what information does HA know that mobile node does not? Patil – how the HA know more than the mobile is out of scope of this WG. Question is do we need to use signaling from HA to perform choice of interface. George – you can have HA remove binding COA currently. Patil – use of binding revocation is somewhat drastic for this case. George – why on a per flow basis. Ryuji – binding revocation is heavy process for mobile-ip. Kent – not clear why we need flow binding revocation. More useful is mobile node policy. George – discussion of inter-interface flow has been discussed in great detail on mail list. 4. Flow binding transport http://tools.ietf.org/html/draft-ietf-mext-flow-binding-03 George - 15 min * TSV Directorate Review o Added stronger health warning wording against per packet load balancing due to is potential effect on TCP o Action Field Values reduced * Now only “discard” and “n-cast” o “Forward” is implemented as “n-cast” with only on BID * FID-PRI filed clarified * Many editorial/clarifications/bugs * Terminology * Rename “n-cast” to “forward” * Bug-fix Document is ready for WG Last Call Patil – what descriptors can be sent in traffic selectors? George – detail of descriptors is in different document. 5. Flow binding bit pattern format http://tools.ietf.org/html/draft-tsirtsis-mext-binary-filters-00 George - 10 min * “Flow Descriptors” are renamed to “Traffic Selectors” * Define default traffic selectors o Focus on matching main network and transport layer fields for identification o Use binary format Description of IPv4 TS and IPv6 TS from document. * Question on Pointers. o Can identify and byte at any layer o Does not require the receiver to know anything about the structure o the packet Discussion (are pointers good or evil?) Marcelo – pointers appear to be bad. If anything changes you may not be pointing to right object. George – pointer is there to identify things that are not readily identifiable by other means. Marcelo – do not believe this is reliable to use pointers. Julien – Need use case Ryuji – don’t believe we need this. What does this add? George – Can be deployed layer so long as we reserve flag. Marcelo suggests accepting document for WG without pointers. No objections and weak consensus. 6. HA reliability http://tools.ietf.org/html/draft-ietf-mip6-hareliability-05 Ryuji - 10 min * 3 years since wg draft 00 * Many reviews * Last modifications o Key Management Mobility Capability (k) bit handling o Replacing the HA switch message with the new Home Agent Kekey message * Defined new message Kent – not clear why we need this. Is there a reason why we need new message versus switch message? Ryuji – new message is for rekeying. Marcelo – asked for an obtain commitment for serious review by three individuals prior to release for Last Call. 10. DHCPv4 Options for Home Information Discovery in Dual Stack MIPv6 Behcet - 10 min Patil – Is needed George – Agreed is needed. Is this a DHCP item or MEXT? 7. Issues with MIP6 deployment Suresh - 10 min http://www3.ietf.org/proceedings/75/slides/mext-0.ppt Presented slides. Patil and George – most issues is until IPv6 is deployed CMIPv6 is not going to be deployed. George – Maybe we now have to explain how all the options fit together. Dino – Have you considered starting over from scratch and developing something better – simpler (seriously). Patil – Lots of work done. Fresh restart doesn’t make sense. Dino – you have experience but it is heavy weight. So you have learned a lot. You are not starting from scratch. Suresh – perhaps cut the current protocol to bare minimum and then add extensions and complexity later. The problem is the multitude of extensions may not work well together. Charlie Perkins – MIPv6 was started from scratch from MIPv4. Not working in vacuum. Security requirement really complicated things. FMIP added additional complexity. Working on a generic tunneling mechanism may greatly simplify things. If we went through spec and hacked and slashed things that probably are not required and don’t really work is something Charlie is fine with. Dino – cut the fat instead of starting from scratch. Kent – implementers generally cherry pick what they want to use. People already select what they need. Suresh – what happens when you are multi-vendor network causes interoperability problems. Kent – people haven’t been deploying because there hasn’t been a need. Do not want heavy-weight security implementation. Nothing really precludes deployment except security complexity. 8. Present the implementation issues with IPsec/IKEv2 w.r.t. DSMIP6 http://tools.ietf.org/html/draft-patil-mext-mip6issueswithipsec-01 Charlie/Basavaraj - 15 Mins Dino - have you thought about starting from scratch ... Julien - Here we are talking about signaling security only? Charlie - this is not just security, it is how you get natural IKE implementation to work with MIPv6 Julien - If BUs where over UDP IPSEC interactions would be simpler Charlie - This sounds like a large change but if it works and people like it why not Kent - Some SDOs have defined in use of MIPv6 but picked Auth-option instead of IPSec. We do need alternatives but we already have one and it is referenced by SDOs Julien - But we will still have the NAT Traversal issue Kent - No, it is the IPsec part that causing this, and the fact that two ports are used Someone - very few advanced IKEv2 implementations out there so keep that into account. And some implementations do not implement everything which may play into some of the issues Marcelo - just to get a feel of what people think, how many thing we should move away from IKE >some discussion< A number of people indicated yes, some said no Dino - I say yes because IPsec drains your battery and you do not need this level of security for this Vidya - only ESP encryption drains the battery, here we only use it for authentication Julien - Whatever you use you need to compute authenticators, it is the same thing 9. Alternate security solution http://tools.ietf.org/html/draft-korhonen-mext-mip6-altsec-01 (Jouni Korhonen) - 15 Mins DSMIPv6 issues with IPsec -------------------------------- Alper - do you require a cert in the mobile? Jouni - no, the EAP-GPDK example is not a good one, Dirk - maybe you can use server based certificates on TLS Alper - but this is not mutual security Dirk - this is just to create a secure pipe, and then you need some mechanism on top Alper - why don’t you use this to bootstrap and key for auth-option. Jouni - I actually wrote this kind of solution before switching to this but decided to change it but there was interest in this Jean-Michel - you negotiate security between MN and HAC and then transfer it to HA what if the HAC is compromised? Also the draft says you are using ESP Raj - packet format looks like ESP but we are not actually using it Jouni - the draft needs to be more clear but there are no IPSEC SAs etc Vidya - that tells you ESP was sufficient to protect the traffic. What does it mean to secure a network layer protocol with transport security? Are you making MIP a transport layer protocol? Jouni - TLS is used to secure traffic HAC not the data traffic. You use the keys to secure the traffic. Vidya - you use the TLS channel to extract keys for MIPv6. There is no such thing in TLS today Dirk - but there is EAP-TLS so you can do it. Vidya - but EAP defines the key management not TLS Dirk - we just use TLS to create secure tunnel and then exchange whatever security you need on top Marcelo - Let's stop and see where we are. In last meeting we asked people to define an alternative mechanism for discussion. We need to understand the proposal and see if it makes sense and if it solves problems Jean-Michel - maybe we should pass this to IPsec group to see what they think Marcelo - we have security AD and the expertise here Raj - the fact is that implementers are not going to work with this. We need to simplify Marcelo - OK, lets discuss this on the list