1 / 10

Design Decisions for Future MIPv6 RFC: Enhancing Protocol Efficiency

Explore design decisions for future MIPv6 RFC, including piggybacked signaling, binding security, unverified Home Address Options, and stronger authorization mechanisms. Delve into challenges and proposals regarding protocol enhancements.

carrington
Télécharger la présentation

Design Decisions for Future MIPv6 RFC: Enhancing Protocol Efficiency

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. Issues beyond the base RFC- Parallel RFCs and future RFCs MIPv6 Design Team March 19th, 2002

  2. Parallel and/or future RFC work In order to produce a base MIPv6 RFC soon… … work should be done in a separate RFC if it is • not absolutely essential for MIPv6 to work, • has some issues that need to be specified and analysed, AND • is technically possible to add later in a backward compatible way

  3. Parallel and/or future RFC work • Capturing the design decisions behind MIPv6 • Piggybacked signalling on payload packets • Binding Security Associations for improved RR performance • Use of unverified Home Address Options • Stronger IFL authorization mechanisms, e.g. CGA • AAA-based IFB authorization mechanisms • Using IPsec as the sole MN-CN BU authorization mechanism

  4. Challenge • Which one is first submitted to the RFC editor: • The MIPv6 base specification • An extension to the MIPv6 base specification

  5. Piggybacking • Proposals exist, discussion on IPsec details and APIs, on whether to use another new header or DO • Flag fields in the HOTI, HOT messages can be used to indicate support and desire for piggybacking • After both peers agree to piggybacking, it can be used for all subsequent signalling • With the potential exception of 2a/2b that need IPsec protection from the HA to the MN

  6. Unverified Home Address Option • Proposals exist, discussion on socket API modification requirements etc. • A node that supports unverified Home Address Option use can later optimistically assume the peer supports them too, and act on a Binding Missing message if it does not

  7. Binding Security Associations • Proposals exist, some security analysis remains • Flag fields in the RR messaging can tell the peers if the other one supports a longer-lasting BSA • For instance, if a HOTI/HOT can be omitted in quick movements, the COTI/COT messages can be run instead

  8. Stronger IFL authorization • Proposals exist, discussion on details, IPR, links to ND protection, … • Bit method allows secure agreement whether to use RR or one of the better schemes (bidding-down) • A selection between the better schemes can take place using flags in HOTI/HOT (bidding aside)

  9. AAA-based IFB authorization • No proposals • Selection as for stronger IFL methods, or guided by AAA

  10. IPsec as sole CN/MN authorization method • Technically easy now with the new protocol • Some security issues to describe when this can be allowed, what the certificates must contain etc • Either flags or IPsec policy or both can be used to allow this. • No bidding down problem if policy explicitly disallows RR and only allows IPsec-based MH • RR can be turned off (if that’s what we want) if MIPv6 and IPsec can talk to each other through an API

More Related