1. 69th IETF, 26 July 2007 Michael Behringer Francois Le Faucheur
A Framework for RSVP Security Using Dynamic Group Keying draft-behringer-tsvwg-rsvp-security-groupkeying-00.txt
69th IETF, 26 July 2007 
Michael Behringer
Francois Le Faucheur
69th IETF, 26 July 2007
draft-behringer-tsvwg-rsvp-security-groupkeying-00.txt

2. Where are we coming from?
Writing Security Considerations section for each new “RSVP extension for Foo” I-D (painfully) showed that:
Applicability of existing RSVP security mechanism is not sufficiently documented
Existing key approaches have limitations
New key approaches could help alleviate/remove some some limitations
69th IETF, 26 July 2007
draft-behringer-tsvwg-rsvp-security-groupkeying-00.txt

3. Per Neighbor / Interface Keys for RSVP Authentication
today
Per Neighbor / Interface Keys for RSVP Authentication
Shared keys (K2, K3, K4) per peer / interface
Today typically statically configured
Operationally heavy  typically not used K3
(PATH)3 R3 K3
(PATH)2 K2 K2 K4 R1 R2
(PATH)4
non-RSVP K4 R4
69th IETF, 26 July 2007
draft-behringer-tsvwg-rsvp-security-groupkeying-00.txt

4. Dynamic Group Keying for RSVP draft-weis-gdoi-for-rsvp-00
new
proposal
Dynamic Group Keying for RSVP draft-weis-gdoi-for-rsvp-00
Use a group key server (GKS) to distribute group keys (GK) and policy to RSVP nodes; used for RSVP Authentication
GDOI distributed group keys are dynamically provisioned
 easier to use than static peer/if keys
GKS GK GK GK R3 GK R1 R2 GK R5 R4
zone of trust
69th IETF, 26 July 2007
draft-behringer-tsvwg-rsvp-security-groupkeying-00.txt

5. Objective of this Document
Different keying approaches for RSVP
traditional: per peer, per interface
new: per group (GDOI)
Different security, applicability
Usage: RSVP Authentication and Encryption
Goal of document:
describe applicability, security of these keying approaches for RSVP
69th IETF, 26 July 2007
draft-behringer-tsvwg-rsvp-security-groupkeying-00.txt

6. Per Neighbor / Interface Keys
Works intra-domain
Works inter-domain
Does not work easily across non-RSPV nodes
Note: regular RSVP (without authentication) does!
Key 3 R3
PATH R1 R2 R5
Key 4
non-RSVP R4
which key to use?
69th IETF, 26 July 2007
draft-behringer-tsvwg-rsvp-security-groupkeying-00.txt

7. Group Keys Work intra-domain
Do not work inter-domain (not applicable).
Assume: domain = zone of trust
 Cannot apply same key across zones of trust
Works across non-RSVP nodes
Group Key
PATH R3 R1 R2 R5
Group Key
non-RSVP R4
use group key!
69th IETF, 26 July 2007
draft-behringer-tsvwg-rsvp-security-groupkeying-00.txt

8. Impact of Subverted Nodes
Subverted: Not trusted
Under control of hacker, misconfigured, buggy, etc
Single subverted node can
reserve all bandwidth through it  local DoS, theft of service
modify / fake path message
global impact, since rsv message goes end-to-end
fake src / dst  potential DoS anywhere in domain
fake phop  potential DoS, local
modify / fake reservation message
local impact, since rsv message goes hop by hop
69th IETF, 26 July 2007
draft-behringer-tsvwg-rsvp-security-groupkeying-00.txt

9. Impact of Subverted Nodes – Protection with Authentication
With peer / interface keys:
Path message:
Can still fake all fields, including src/dst
Can create new fake messages
Rsv message:
Can fake and create, but local impact only
With group keys:
Same impact
69th IETF, 26 July 2007
draft-behringer-tsvwg-rsvp-security-groupkeying-00.txt

10. What Does RSVP Authentication Do?
RSVP Authentication (with any key type) ensures the origin and integrity of the message (*); it does not ensure the correctness of the message content.
(*) and replay protection
69th IETF, 26 July 2007
draft-behringer-tsvwg-rsvp-security-groupkeying-00.txt

11. Conclusions peer or interface key group key works intra-domain y
works inter-domain n
works with non-RSVP hops in path
protects against subverted nodes
Usage of the key for encryption (instead of authentication) has the same properties as shown in the above table for authentication.
69th IETF, 26 July 2007
draft-behringer-tsvwg-rsvp-security-groupkeying-00.txt

12. Questions Does the document add value?
What are the areas that need be added, expanded,…?
We solicit review and further input
69th IETF, 26 July 2007
draft-behringer-tsvwg-rsvp-security-groupkeying-00.txt