1 / 7

58th IETF, Minneapolis Jari Arkko, Ericsson Research NomadicLab

Issues in the SEND base document draft-ietf-send-ndopt-00.txt http://www.piuha.net/~jarkko/publications/send/issues. 58th IETF, Minneapolis Jari Arkko, Ericsson Research NomadicLab Pekka Nikander, Ericsson Research NomadicLab. Issue Statistics.

virgo
Download Presentation

58th IETF, Minneapolis Jari Arkko, Ericsson Research NomadicLab

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 in the SEND base documentdraft-ietf-send-ndopt-00.txthttp://www.piuha.net/~jarkko/publications/send/issues 58th IETF, Minneapolis Jari Arkko, Ericsson Research NomadicLab Pekka Nikander, Ericsson Research NomadicLab

  2. Issue Statistics • Between draft-arkko-send-ndopt-00 and draft-ietf-send-ndopt-00: • 25 issues • 3-4 editorial, the rest were technical • many technical issues solved when ND options chosen over IPsec • Currently 6 issues not fixed in the document • 5 with a proposed solution • 1 open one http://www.piuha.net/~jarkko/publications/send/issues

  3. Issues Resolved, not in the latest draft: • 13 - Editorial issues from Pasi and Valtteri • 30 - Change back the RSA-PKCS version number Being discussed: • 27 - DCS and DCA semantics • 28 - DCS source address • 31 - Source address selection and CGA addresses • 17 - Different functions of Redirect

  4. 27 - DCS and DCA Semantics • DCS and DCA transmission rules largely copied from RS and RA • It would be more natural to just trigger the process from receiving a message with an unknown signer • The two additional things that are required: • Rate limitation • Allow the router to unicast or multicast the message, depending on situation • As a result, periodic DCA is not needed • Text proposal worked out on the list, appears to be adopted

  5. 28 - DCS source address • Background part 1: DCA source required to be link-local • Background part 2: RA source L-L, RS source anything • Current specification: DCA source is anything • Question: Should we restrict this to saying its link-local? • What if someone sends a DCS using a wrong global address, say, from a nearby link? • (I may not fully understand why 2461 did things in the way it did) • Seems safest to require DCA source to be link-local?

  6. 31 - Source Address Selection and SEND • Is there a dependency between source address selection and SEND? • If there are CGA and non-CGA addresses, SEND can only provide security if CGA addresses are chosen • Should there be a rule to prefer CGA addresses? • What the priority of the rule should be? • Should there be an API to switch the default? • Suggestion: • Generally, this does not matter as CGA is normally on/off • There should be a rule, in one of the SEND documents • The priority of the rule should be high • No API is needed, RFC 3484 already has a config table

  7. 17 - Different Functions of Redirect • The design of SEND only considered Redirect as a message to inform of a better router • Francis pointed out there are other functions: • Link-layer address update by the node itself • Specify link-layer address of an off-link destination which is in fact on link (ATM & NHRP) • We can easily take care of the editorial part of this issue • Any security implications? • Redirect from a host would use CGA, from a router certs • Appears to be OK, as long as the document takes care of this

More Related