Implications of Trust Relationships for NSIS Signaling

Download Report

Transcript Implications of Trust Relationships for NSIS Signaling

RSVP Security Properties
(draft-ietf-nsis-rsvp-sec-properties-00.txt)
Author:
Hannes Tschofenig
First-Peer Issue

Some information is required to protect RSVP messages from an
end host.
— Identity
— Mechanisms
— Security association
— etc.

RSVP was initially designed for signaling with enterprise networks
Building block => architectural considerations
Mobility adds more requirements


[email protected]
Next Peer Issue (1/3)
RSVP
Path +
Integrity
(R1<->R4)
Router 3
What key should be selected
to protect the signaling message?
RSVP
Path
Router 1
RSVP
Path +
Integrity
(R1<->R4)
Router 4
[email protected]
Next Peer Issue (2/3)
Cryptographic
verification failed!
Router 3
PathErr
(I am Router 3)
Router 1
PathErr
(I am Router 3)
Router 2
Router 4
[email protected]
Next Peer Issue (3/3)
RSVP
Path +
Integrity
(R1<->R3)
Router 1
RSVP
Path +
Integrity
(R1<->R3)
Cryptographic
verification successful!
Router 3
Router 2
Router 4
[email protected]
Last Peer Issue



Some security protocols shown an asymmetry in message
processing.
Roles are reversed for last peer communication
Examples: Kerberos (User-to-Server)
Router 2
Router 1
Learn Kerberos principal
name (e.g. via DNS)
 Obtain Kerberos ticket
 Include ticket in RSVP
Policy object
Router 3

User to Server
Host A
[email protected]
“User” to User
Host B
Implications of IPsec protected data traffic



RFC 2207 defines 3-tuple <SrcIP, DstIP, SPI> as a flow identifier.
Assumptions are:
— SPI for a given flow can be retrieved
— IPsec protection is end-to-end
— SPI does not change during the lifetime of a QoS reservation
RFC 2207 does not cover:
— IPsec protection independent of end points (covered by RFC2746)
— IPsec protection starts/ends at one of the RSVP signaling end
points only (IPsec nested – VPN, secure network access case)
[email protected]
IPsec protection of RSVP signaling messages

Theoretically IPsec could be applied to RSVP signaling messages
BUT
— Path, PathTear, ResvConf messages are addressed to the
destination address.
— If there is more than one possible path then custom IPsec
protection might be very difficult.
— Possible IPsec traffic selector is: Protocol number (46) (and
Router Alert IP Option)
— IPsec can only be used in tunnel mode to protect signaling
messages between two RSVP nodes.
— Tunnel mode can cause RSVP packets to use a different path
than the data path.
[email protected]