RSVP Security Properties draftietfnsisrsvpsecproperties01'txt

1
RSVP Security Properties(draft-ietf-nsis-rsvp-sec
-properties-01.txt)

• Author
• Hannes Tschofenig

2
Update

• Added Sections to cover
• First hop, next hop, last hop issues
• IPsec protected data traffic
• IPsec protection of RSVP signaling messages
• Addressing problem of combining discovery with
  signaling message delivery
• Removed section about AAA interaction since it is
  covered by a separate draft (draft-tschofenig-nsis
  -aaa-issues-01.txt)

3
Next Steps

• Editorial clean-up and shortening.
• Reference to some other security work in this
  area.
• Comments to the draft are welcome.

4
Backup Slides
5
Summary of the draft (1/3)

• Discovery and signaling message delivery should
  be separated.
• For some applications and scenarios it cannot be
  assumed that neighboring RSVP aware nodes know
  each other. A separate discovery mechanism should
  be provided.
• Addressing for signaling messages should be done
  in a hop-by-hop fashion.
• Standard security protocols should be used
  whenever possible.
• Key Management is required. Relying on manually
  configured keys only is insufficient.

6
Summary of the draft (2/3)

• The usage of public key cryptography for
  authorization tokens, identity representation,
  selective object protection, etc. is likely to
  cause fragmentation.
• Public key-based authentication and user identity
  confidentiality provided with RSVP require some
  improvement.
• Public key based user authentication only
  provides entity authentication. An additional
  security association is required to protect the
  signaling message.
• Data origin authentication should not be provided
  to non-RSVP nodes (such as the PDP).

7
Summary of the draft (3/3)

• Authorization and charging should be better
  integrated in the base protocol. Some spots are
  missing. The RSVP policy handling requires an
  improvement.
• Selective message protection should be provided.
  A protected object should be recognizable from a
  flag in the header.
• Confidentiality protection is missing and should
  therefore be added to the protocol.
• Parameter and mechanism negotiation should be
  provided.