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

1
The CGA header approach for SENDdraft-nikander-s
end-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
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 CGAAH headers,
  not at ND
• ND doesnt 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 CGAAH
  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, orPekkas 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?