[secdir] draft-ash-gcac-algorithm-spec-03

[Rob Austein <[e-mail]>]

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.