Subject: [secdir] secdir review of draft-ietf-tsvwg-admitted-realtime-dscp-05

From: Alexey Melnikov <[email-masked]>
Date: Fri, 21 Nov 2008 23:44:47 -0600

I have reviewed this document as part of the security directorate's 
ongoing effort to review all IETF documents being processed by the IESG. 
These comments were written primarily for the benefit of the security 
area directors.  Document editors and WG chairs should treat these 
comments just like any other last call comments.

This document requests one Differentiated Services Code Point (DSCP)
from the Internet Assigned Numbers Authority (IANA) for real-time
traffic classes similar to voice conforming to the Expedited
Forwarding Per Hop Behavior, and admitted using a call admission
procedure involving authentication, authorization, and capacity
admission.

This document also recommends that certain classes of video traffic
described in RFC 4594 and which have similar requirements be changed
to require admission using a Call Admission Control (CAC) procedure
involving authentication, authorization, and capacity admission.

For a person not familiar with the underlying technology,
I found the Security Consideration section to be insufficiently detailed
about threats. While the list of threats seems to be adequate,
it would be useful to have some pointers to documents describing possible
remedies (for example how to achieve adequately strong proof of identity),
or a clear statement that the protocol doesn't provide such facility.

_______________________________________________
secdir mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/secdir

---

From: Fred Baker <[email-masked]>
Date: Sat, 22 Nov 2008 17:34:30 -0600

> or a clear statement that the protocol doesn't provide such facility.

Would a reference to 4542 be sufficient?

My sense is that the threat model on a AAA service is likely to be  
documented in something related to AAA services, and frankly you are  
more likely to have a pointer to the document than I. Similarly, the  
threat model regarding people getting capacity allocated to them that  
shouldn't have been seems implicit in RFC 1633, the documentation of  
RSVP, and the documentation of NSIS - protocols designed explicitly to  
prevent that from happening. There is of course a threat model for  
implementing such a protocol as well, which is mentioned in RFC 4230.

if I'm missing something and you want more, some idea of what kind of  
threat model you are looking for would be helpful.
_______________________________________________
secdir mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/secdir

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 25 Nov 2008 19:34:38 +0000

Hi Fred,

> Would a reference to 4542 be sufficient?

It looks like a reference to section 2.4 of RFC 4542 would be helpful.

> RSVP, and the documentation of NSIS - protocols designed explicitly 
> to  prevent that from happening. There is of course a threat model 
> for  implementing such a protocol as well, which is mentioned in RFC 
> 4230.

I think a reference to RFC 4230 would be helpful as well.

> threat model you are looking for would be helpful.

I was reading your Security Considerations:

   A major requirement of this service is effective use of a signaling
   protocol such as RSVP, with the capabilities to identify its user
   either as an individual or as a member of some corporate entity, and
   assert a policy such as "routine" or "priority".

   This capability, one has to believe, will be abused by script kiddies
   and others if the proof of identity is not adequately strong

My question after reading this part was "how one can make make proof of identity sufficiently strong?".
So some pointers helping a reader to find this information would be useful here.

   or if
   policies are written or implemented improperly by the carriers.  This
   goes without saying, but this section is here for it to be said...