Security AD Issues with CCAMP I-Ds in IESG Review

1
Security AD Issues with CCAMP I-Ds in IESG Review
Adrian Farreladrian_at_olddog.co.uk
2
Normal Process

• I-D completes WG last call
• Includes review of the Security Considerations
  section
• I-D is reviewed by a Routing AD
• Full review of the I-D including Security
• IETF last call
• I-D goes to IESG for review
• Security ADs review the work
• May use Security Directorate to help with the
  review

3
Security Concerns with CCAMP Work

• Several recent I-Ds have caused concern
• For example, Inter-domain TE Framework (RFC 4726)
• Our answer has been
• To tighten the language in the Security
  Considerations section
• To refer forwards to Luyuans work
• Two I-Ds are currently blocked with specific
  security concerns

4
Graceful Restart - Issues

• draft-ietf-ccamp-rsvp-restart-ext-08
• What would happen if the downstream neighbour of
  a restarting node sent a false RecoveryPath
  message?
• Might be an accident
• AD is worried about malicious or subverted LSRs
• Could the RecoveryPath message cause the
  restarting node to behave differently/wrongly?
• Data plane?
• Control plane?

5
Graceful Restart - Responses

• Response and discussion in private emails
• Whole thread copied to CCAMP list
• RSVP-TE trust model is peer-to-peer
• Sender of RecoveryPath message is authenticated
• Therefore, risk is of subversion
• Why is this particular risk so important?
• Why doesnt downstream LSR simply misbehave?
• Send Resv with bogus information
• Install broken forwarding path
• Forward bogus Path message
• RecoveryPath is verified against data plane on
  restarting node (which includes outgoing
  interface)
• Specific parameters have been discussed (ERO,
  etc.)

6
RSVP-TE Call Issues

• Is the use of the Notify message in end-to-end
  communication a new concepts?
• Do existing uses of Notify use security
  associations?
• How are keys established with potentially many
  Notify recipients?
• Is authentication a necessary part of Call
  processing?
• Is automated key exchange/distribution needed?

7
RSVP-TE Call - Responses

• Security is applicable to Calls
• No change in processing for Notify messages
• Security association may be formed between Notify
  sender and Notify receiver
• RSVP-TE security
• IPsec if Notify is tunnelled
• Notify message may be sent hop-by-hop
• No new security associations required

8
Next Steps

• For the Restart work
• AD would like us to describe all parameters on
  RecoveryPath
• Lots of work to document thoroughly
• Any volunteers?
• For the Call draft
• AD would like us to do an RFC 4107 analysis
• Examines the need for key management
• Helps select the appropriate mechanism
• Might lead to additions to the I-D
• Face-to-face discussions at this IETF
• Try to cover the specific security issues
• Attempt to clarify the security framework
• Look for a way forward