The cga header approach for send draft nikander send ipsec 00 txt
1 / 12

The CGA header approach for SEND draft-nikander-send-ipsec-00.txt - PowerPoint PPT Presentation

  • Uploaded on

The CGA header approach for SEND draft-nikander-send-ipsec-00.txt. IETF 57, Vienna Pekka Nikander, Ericsson Research. Presentation outline. What is CGA header approach Where the data is carried compared to ND options Input and output processing How the functionality is distributed

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

PowerPoint Slideshow about 'The CGA header approach for SEND draft-nikander-send-ipsec-00.txt' - elijah-donovan

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
The cga header approach for send draft nikander send ipsec 00 txt

The CGA header approach for SENDdraft-nikander-send-ipsec-00.txt

IETF 57, Vienna

Pekka Nikander, Ericsson Research

Presentation outline
Presentation outline

  • What is CGA header approach

    • Where the data is carried compared to ND options

  • Input and output processing

    • How the functionality is distributed

  • Mixed mode processing

  • Comparison with ND options

  • Summary

The cga header approach





ND Msg

ND Opts







The CGA header approach


Input processing
Input processing

  • CGA header processing

    • Verify that the source address matches with the key and parameters in the CGA header

    • Create an SA, associated with source address

  • IPsec processing

    • Select the SA, based on the source address

    • Verify the signature

  • ND processing

    • Verify the nonce, if a solicitated announcement

    • If mixed mode is used, mark address as protected or unprotected based on whether AH was used or not

Output processing
Output processing

  • ND processing

    • Add a nonce

  • CGA header processing

    • Add a CGA header, if the source address is a CGA address

  • IPsec processing

    • Use the source address to select an SA

    • If found an SA, create a signature and add AH

    • Otherwise send out without AH

Other technical details
Other technical details

  • Nonces are used as a part of ND

    • Only meaningful if IPsec indicates that AH was used?

  • Timestamps protect from replayed CGA+AH headers, not at ND

    • ND doesn’t see timestamps, nor replayed packets

    • CGA verification fails if timestamp is too old

    • AH verification fails if timestamp has been tampered with

    • Is this the right approach?

  • Authorization can use certificates or pre-shared keys

    • CGA header is not included

    • SAs are pre-configured or created when receiving certs

Transition mixed mode
Transition/mixed mode

  • (Several possible approaches, here just one)

  • Two kinds of addresses

    • Protected addresses

      • IPsec outgoing SPD indicates AH if used as source

      • CGA header added before consulting IPsec SPD

    • Unprotected addresses (non-SEND ones)

      • IPsec outgoing SPD indicates PASS if used as source

    • Need not be in separate address spaces as in the WG draft

  • DAD as in the current WG draft

  • ND cache indicates secure/unsecure status

    • Same as in the ND options approach

Issues with the mixed mode
Issues with the mixed mode

  • IPsec must indicate whether AH was used or not

    • Required to be able to label ND cache entries as secure or unsecure

  • What if ND node solicitates for a protected address?

    • Answer would contain AH due to the SPD entry

    • Possible solution: create a temporary, destination bound outgoing SPD entry indicating otherwise?

      • Requires and ability from ND to create SPD entries

  • Source address selection becomes more complex

    • Must select a protected or an unprotected source address based on the status of the destination address

Comparison with nd options
Comparison with ND options

  • (Explicit pros and cons on the next two slides)

  • Functional complexity roughly the same

    • both must basically do the same things

  • Functionality distributed over several places

    • therefore implementing may be complex than with ND opts

  • Public key operations at AH, not ND

  • Requires public key AH and SPD entries that use only the source address, not destination

    • Use ::/0 as destination, and forget IPsec WG opinions?

  • No separate address spaces for SEND and ND

    • For ND options this is clear, with the CGA+AH approach there are a few remaining issues to be solved...


  • Consistent with RFC 2461 security approach

  • Modularity; separate functions for

    • key management (CGA / certs / pre-shared)

    • authentication (PK based AH)

    • application layer security processing

  • Could be used for all traffic, not just ND

  • Potentially useful in other applications


  • Functionality distributed over several places

    • Harder to analyse, harder to implement correctly

    • Timestamp and key information not directly available at ND, only indirectly

  • Requires an interface between IPsec and ND

    • Indication from IPsec to ND whether AH was used

    • Source address based SA selection

    • Ability to create SPD entries from ND?

  • Requires public key AH

    • Harder to implement than PK operations at ND?

  • Extra ND messages in some cases (DAD)

  • May have unknown DoS problems

Summary or pekka s opinions
Summary, orPekka’s opinions

  • Functionally there is little difference

  • ND options is clearly easier to implement

  • CGA header + AH is more consistent with the RFC2461 security approach (”use AH”)

  • Mostly an architectural issue

    • Should IPsec include PK crypto at AH/ESP at all?

      • This is also the question wrt. source address based SA selection, since PK is source bound

    • Is in-line KMP allowed? (IPsec WG rejected SKIP)

    • Should IPsec be used to protect IP layer signalling at all?