1 / 12

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

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

elijah-donovan
Télécharger la présentation

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. 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. The CGA header approach for SENDdraft-nikander-send-ipsec-00.txt IETF 57, Vienna Pekka Nikander, Ericsson Research

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

  3. IPv6 CGA AH ICMPv6 ND Msg ND Opts Timestamp Parameters Key Type Length Nonce The CGA header approach Signature

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

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

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

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

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

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

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

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

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

More Related