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

From: "Luyuan Fang (lufang)" <[email-masked]>
Date: Thu, 18 Dec 2008 03:01:02 -0500

Donald,

Thank you for your review and comments. 

We have addressed all your comments (including clarify PE and adding BCP
reference), as well as other IESG review comments in 04 draft which is
just posted. 

Thank you for your time and help,

Luyuan 

________________________________

From: Donald Eastlake [mailto:[email-masked]] 
Sent: 21 November 2008 04:02
To: [email-masked]; [email-masked]; George Swallow (swallow); Loa
Andersson; [email-masked]; [email-masked]; Luyuan Fang
(lufang)
Subject: draft-ietf-mpls-ldp-igp-sync-03.txt

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

---

From: "Donald Eastlake" <[email-masked]>
Date: Thu, 18 Dec 2008 11:43:36 -0500

Thanks. All of my security related comments have been addressed in -04.
Donald

On Thu, Dec 18, 2008 at 3:01 AM, Luyuan Fang (lufang) <[email-masked]>wrote:

>  ------------------------------
> *From:* Donald Eastlake [mailto:[email-masked]]
> *Sent:* 21 November 2008 04:02
> *To:* [email-masked]; [email-masked]; George Swallow (swallow); Loa
> *Subject:* draft-ietf-mpls-ldp-igp-sync-03.txt
>
>  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.
> 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.
> 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"
>
> Thanks, Donald

--