The cga header approach for send draft nikander send ipsec 00 txt
This presentation is the property of its rightful owner.
Sponsored Links
1 / 12

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


  • 93 Views
  • Uploaded on
  • Presentation posted in: General

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

Download Presentation

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

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

IPv6

CGA

AH

ICMPv6

ND Msg

ND Opts

Timestamp

Parameters

Key

Type

Length

Nonce

The CGA header approach

Signature


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...


The cga header approach for send draft nikander send ipsec 00 txt

Pros

  • 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


The cga header approach for send draft nikander send ipsec 00 txt

Cons

  • 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?


  • Login