1 / 4

DSMIPv6 Update draft-ietf-mip6-nemo-v4traversal-06 hesham@elevatemobile

DSMIPv6 Update draft-ietf-mip6-nemo-v4traversal-06 hesham@elevatemobile.com. Status. Draft finished WG LC with comments. Most comments were editorial. Major issue about the interaction between DSMIPv6 and IKEv2.

jada
Télécharger la présentation

DSMIPv6 Update draft-ietf-mip6-nemo-v4traversal-06 hesham@elevatemobile

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. DSMIPv6 Updatedraft-ietf-mip6-nemo-v4traversal-06hesham@elevatemobile.com

  2. Status • Draft finished WG LC with comments. • Most comments were editorial. • Major issue about the interaction between DSMIPv6 and IKEv2. • No consensus within the WG, therefore the security review resulted in the selection of a solution. No objections were raised after the security review. • Selected approach: Use RFC 3498 for SA establishment and for sending secure payload. Use DSMIPv6 tunnel to send BU/BA as described in the draft. • Assumption: UDP tunneling is NEVER used when the MN is in an IPv6-enabled network. • The use of Mobike is optional. • Issue addressed in the security considerations section in the draft after going through WG consensus.

  3. Comments on the Security considerations section • Comment from Karen: Update of local SA in the MN should only be done after the receipt of the BA. • Comment from Karen: Mention that the type of tunnel SA may change from RFC4301 type tunneling to RFC 3498 (depending on whether a NAT is in the path) • Comment from Pasi: Mention that this NAT traversal solution has the same vulnerabilities as RFC 3519 and not UNSAF vulnerabilities (current draft mentions UNSAF). • Comment from Pasi, George, Vijay: The MN SHOULD deregister its RO BCEs with CNs when it moves from an IPv6 network to an IPv4 network. • Several editorial comments from George.

  4. Next steps • Send a new security considerations section to the list after updating it based on the comments. This should happen ASAP. • Progress the draft to IESG?

More Related