[Rsvp] RE: doubt

[Tschofenig Hannes]

hi 

> > my personal opinion: the policy objects tried to repair the 
> missing key
> > management to some extend (i.e. they provide the user 
> identity for the
> > purpose of policy based admission control). 
> 
> No.  Policy and hop-by-hop integrity perform complementary functions.

if you use kerberos within the policy object then you can use the session
key for the integrity object to protect the messages. hence there is a
relationship between the two. without a policy object would still have to
provide an authentication and key exchange protocol to establish the key (if
not manually established).

if you look at the following figure which shows a typical end-to-end
signaling scenario. 

  +------------------+   +---------------+   +------------------+
  |                  |   |               |   |                  |
  |  Administrative  |   | Intermediate  |   |  Administrative  |
  |     Domain A     |   |   Domains     |   |     Domain B     |
  |                  |   |               |   |                  |
  |                 (Inter-domain Communication)                |
  |        +---------+---+---------------+---+---------+        |
  |  (Intra-domain   |   |               |   | (Intra-domain    |
  |   Communication) |   |               |   |  Communication)  |
  |        |         |   |               |   |         |        |
  |        |         |   |               |   |         |        |
  +--------+---------+   +---------------+   +---------+--------+
           ^                                           v
           |                                           |
  First Peer Communication               Last Peer Communication
           |                                           |
     +-----+-----+                               +-----+-----+
     |   RSVP    |                               |   RSVP    |
     |  Node A   |                               |  Node B   |
     +-----------+                               +-----------+

if you assume that charging of the qos reservation is done in a peer-to-peer
fashion then the RSVP Node A would be charged by domain A and then each
domain charges its peering domain. (charging for the data sender)

hence domain A would require some form of user authentication to perform
credit check functionality. it is likely that the first router would be rsvp
capable. additionally you need to protect the signaling messages (integrity,
replay, etc. protection). 

especially in a mobile scenario you do not have a pre-established key with
the first rsvp router. 

this leads me to the conclusion that you need a key exchange protocol which
establishes a security association which then serves to protect the rsvp
signaling messages. it would not make sense to perform user authentication
at other routers in the same administrative domain. i wouldn't even know a
reason why you would like to do that. you wouldn't want to authenticate the
signaling initiator to intermediate networks along the path. this would
effectively cause some other problems - additionally this is a major shift
in the charging model. 

i once looked at the kerberos / rsvp description of windows 2000 and i had
the impression that they used the policy data object to provide the key for
the integrity object. 


> 
> Hop-by-hop integrity authenticates that the message came from 
> a trusted
> neighboring router in the signaling path and that the contents have
> not been modified in-route.

i agree that the integrity object allows you to protect the signaling
messages. 


if you have this configuration: 

RSVP router X ------> non-RSVP router A ----------> RSVP router Y 

then the rsvp integrity object would disallow the non-RSVP router A to
modify, replay, inject, etc. an RSVP message to the RSVP aware router Y. 

this, however, assumes that you have one or more non-rsvp routers between
rsvp aware routers along the path. this leads us back to our previous
discussion. 


> 
> Policy identifies the sender of the request and is the basis for
> policy based admission control and charging.  A sender gets
> charged for a request, not an intermediate router in the signaling
> path.

this is very true. 

i will send you a document describing two different charging models (once we
have finished it). one charging model is based on peering-relationships
between networks. the other one allows intermediate administrative domains
to charge the end host/initiator directly. i (or better we) would like to
see your opinion. 

> 
> > 
> > the hop-by-hop security is perfectly fine for the charging 
> model currently
> > used in the internet. i will send around a document giving 
> detailed reason
> > s
> > for this statement in the near future. 
> 
> No.  See above.

ciao
hannes

> 
> Bob
>