Subject: [secdir] draft-ietf-mpls-ldp-igp-sync-03.txt

From: "Donald Eastlake" <[email-masked]>
Date: Fri, 21 Nov 2008 04:02:03 -0500

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

This document suggests ways to help where MPLS and MPLS label distribution
(LDP) are intended to run over the links in a network as determined by an IP
routing protocol but, for one reason or another, either transiently or
permanently, IP routing is up on a link but MPLS is not functioning. This
results in the possibility of MPLS frames following a path found by routing
but getting black holed at the link where MPLS is not operational. The draft
also suggests applicability of its suggestions to some types of tunnels.

Security Considerations
   While, admittedly, this relatively short document is about some fairly
simple things relating to MPLS LDP and IP routing, I felt a bit shortchanged
by the Security Considerations section.
   It is my impression that this document, or at least the underlying
protocols it refers to, assume a trusted "provider" world with a secure
perimeter such that "customer" traffic from the uncontrolled outside world
has been tamed / filtered / labeled as it enters this trusted world. The
presence of such clues as "edge-to-edge" and "PE" which, while unexplained
and unexpanded in this document, I assume to be "Provider Edge", lead to
this conclusion. But it would be nice to say this and/or to give a reference
to the Security Considerations section of RFC 5306, which tends to recommend
being secure by only talking to nodes that won't say anything nasty to you.
   The possibilities of Denial of Service caused by the drafts
recommendations are discussed and do not seem particularly serious except,
as the draft says, in case of "operational error or implementation error"
however, I think the reference to "current best security practice" without
any reference or further explanation is a bit vague.

Editorial   Section 5, page 5, first line: Insert "that" after "attack".
   Section 5, page 5, fifth line: Replace "here is to prevent the link to be
used when" with "here prevents the use of the link when"

I am bothered that no author lists a telephone number in the Author's
Addresses section.

Thanks,Donald
=============================
Donald E. Eastlake 3rd   +1-508-634-2066 (home)
155 Beaver Street
Milford, MA 01757 USA
[email-masked]
_______________________________________________
secdir mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/secdir