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

[Sean Turner <[e-mail]>]

Roger.  I’ll keep an eye out for a revision.  

spt

On Dec 15, 2014, at 01:29, Loa Andersson <[e-mail]> wrote:

> 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]