Re: [secdir] secdir review of draft-ietf-mpls-lsp-ping-relay-reply

[Loa Andersson <[e-mail]>]

Sean,

We had a "wrinkle" on this :( ! Two of the authors discovered (very
late) something that needs to be addressed.

I asked the AD to send the ducment back to the working group for "more
work". I hope it be a smooth process, and that we'll get the document
timely back on track again.

Anyhow, I expect that the authors takes care of your comments during the
"more work" process.

/Loa

On 2014-12-14 03:29, Sean Turner wrote:
> Do not be alarmed.  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 with the intent
> of improving security requirements and considerations in IETF drafts.
> Comments not addressed in last call may be included in AD reviews
> during the IESG review.  Document editors and WG chairs should treat
> these comments just like any other last call comments.
>
> Version: 06
> Summary: Ready with some non-security/non-privacy nits.
>
> Ping mechanisms always give me the heebie-jeebies [1]
> because of the security concerns associated with them (i.e., DoS,
> spoofing/hijacking/etc., and unauthorized disclosure).  This document
> specifies an extension to the existing ECHO mechanism in RFC 4379
> and it does nothing to address these concerns in fact it increases the
> concerns wrt DoS. *BUT* it rightly points this increase exposure out in
> the security considerations section.  It provides remediation techniques
> similar to those specified in RFC 4379: rate limit and validate source
> against access list.  This draft, unlike RFC 4379, does recommend that
> operators wishing to not disclose their nodes blank the address out in
> the TLV.  This draft also refers to RFC 4379 for additional security
> considerations.
>
> WARNING - questions and nits follow:
>
> s3 - 1st paragraph: Relayed Echo Reply “replaces” Echo Reply - does this
> mean you’re deprecating the use of “Echo Reply”?
>
> s4.1: Is the outermost label allowed to be set to 255 to support the
> “ping” mode or must it always be set to 1, 2, etc. to support “traceroute"
> mode - as described in RFC 4379 s4.3?   I know s5 is just an example
> but it really looks like this extension is just supposed to be for fault
> isolation.
>
> s4.1 - last paragraph: Does the next initiator put it’s address in the stack
> before or after the previous initiator?  I assume it’s after, but I maybe
> missed that part?  Would be good to state that explicitly.
>
> Cheers,
> spt
>
> [1] http://en.wikipedia.org/wiki/Heebie-jeebies_(idiom)
>

-- 


Loa Andersson                        email: [e-mail]
Senior MPLS Expert                          [e-mail]
Huawei Technologies (consultant)     phone: [phone]