Last Call Review of draft-ash-gcac-algorithm-spec-
|Requested revision||No specific revision (document currently at 04)|
|Type||Last Call Review|
|Team||Security Area Directorate (secdir)|
|Authors||Gerald Ash , Dave McDysan|
|I-D last updated||2012-01-23|
Secdir Last Call review of -??
by Rob Austein
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 describes an experimental "connection admission control" algorithm, that is, an algorithm by which an IP/MPLS service provider's equipment might decide whether or not to allow a new connection such as a new VoIP call, given various constraints such as quality of service issues. The draft is slated for experimental status and cautions against indiscriminate deployment on operational networks. I am sorry to have to say at this late date that I found the Security Considerations of this draft woefully inadequate. The IESG will have to decide to what extent (if any) this matters for document on the experimental track. The algorithm is not a protocol, rather it is layered on top of a barrel full of existing protocols, and appears to be an attempt to provide a uniform and generic decision layer on top of all that. As such, it depends on various parameters carried by the underlying protocols. Nowhere do I see any discussion of the extent to which this makes the algorithm's decisions vulnerable to attacks on any of the underlying protocols (or, more likely, to attacks on whichever happens to be the weakest of the underlying protocols this week). To reader who is not an MPLS expert, it's unclear where one would even begin such an analysis, which is one of the reasons why such things are supposed to be discussed in the Security Considerations. Furthermore, there is very little discussion of threats that might derive from gaming the algorithm itself. The entirety of the Security Considerations section consists of a brief discussion of one threat ("theft-of-service attacks" due to users claiming emergency priority for their flows) with a somewhat opaque claim that RSVP-TE signalling policy can be used to defeat the attack. I see no discussion of other results of gaming the algorithm, such as DoS attacks by allowing new flows when the algorithm should have prevented them, denying resources to legitimate flows by rejecting new flows when the algorithm should have allowed them, tinkering with the bandwidth parameters, etc. In view of the lateness of this review and the experimental status requested, I will understand if the IESG passes this document in spite of these issues. Caveat: As may be obvious from the above, I am not an MPLS expert.