User Identity Policy Element Tim Moore Microsoft

Draft-ietf-rap-user-identity-00.txt Authors Peter Ford - Microsoft Satyen Yadav - Intel Ramesh Pabbati - Microsoft Shai Herzog - IP Highway Presented at Los Angeles IETF meeting

Features Identifies user to a RSVP Policy Hop in a secure manner. –MD-5 shared keys for end systems is hard to deploy and unscalable –Could extend Integrity Object to use User Identities in place of IP identities. Allows remap identity at any RSVP node –disney/world/epcot/mickey -> disney.com Self Identifying Objects –Supports multiple security methods. Can support COPS/RAP framework

Limitations Finite Cost for Security –Kerberos Tickets are ~700 bytes –Certs are longer –Net - works best with only one identity per msg Multicast merge cases are still open –not a wire protocol issue

Multicast Merge What if the merge occurs before policy check - free rider problem –simply a policy issue - move policy to merge points if you want that level of control What identity for merged reservation? –Don’t want huge user lists in RESV msgs

Multicast Merge Sender Router 2 Router 1 Receiver 1 Receiver 2 Receiver 1 RESV message with with ID PE for User 3 RESV message with ID PE for User 1 + User 2 + User 3 RESV message with with ID PE for User 2 RESV message with with ID PE for User 1

Potential Solutions for Multicast Use a network identity (router id, corp network id, etc.). Generate a Group identity of the receivers. –Cost of doing and recording this (for auditing) Don’t use Identity Policy Element –can use currently defined Integrity object

Status MS current plan –Implemented in NT 5.0 beta 2 –Mcast merge - use network id beyond first hop policy node Would like to move forward on stds track –Need other implementations Do we need an overall security framework for RSVP?