slide1 n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
58th IETF, Minneapolis Jari Arkko, Ericsson Research NomadicLab PowerPoint Presentation
Download Presentation
58th IETF, Minneapolis Jari Arkko, Ericsson Research NomadicLab

Loading in 2 Seconds...

play fullscreen
1 / 7

58th IETF, Minneapolis Jari Arkko, Ericsson Research NomadicLab - PowerPoint PPT Presentation


  • 72 Views
  • Uploaded on

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.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about '58th IETF, Minneapolis Jari Arkko, Ericsson Research NomadicLab' - virgo


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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
slide1

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

issue statistics
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

issues
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
27 dcs and dca semantics
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
28 dcs source address
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?
31 source address selection and send
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
17 different functions of redirect
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