Re: [mpls] Kathleen Moriarty's Discuss on draft-ietf-mpls-entropy-lsp-ping-04: (with DISCUSS)

[[e-mail]]

Hi Carlos,

Thanks for adding a few sentences on this.  Let me know when you have text to review.

Thanks,
Kathleen 

Sent from my iPhone

> On Aug 31, 2016, at 11:04 PM, Carlos Pignataro (cpignata) <[e-mail]> wrote:
> 
> Hi Kathleen,
> 
>> On Aug 29, 2016, at 3:26 PM, Kathleen Moriarty <[e-mail]> wrote:
>> 
>> Kathleen Moriarty has entered the following ballot position for
>> draft-ietf-mpls-entropy-lsp-ping-04: Discuss
>> 
>> When responding, please keep the subject line intact and reply to all
>> email addresses included in the To and CC lines. (Feel free to cut this
>> introductory paragraph, however.)
>> 
>> 
>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
>> for more information about IESG DISCUSS and COMMENT positions.
>> 
>> 
>> The document, along with other ballot positions, can be found here:
>> https://datatracker.ietf.org/doc/draft-ietf-mpls-entropy-lsp-ping/
>> 
>> 
>> 
>> ----------------------------------------------------------------------
>> DISCUSS:
>> ----------------------------------------------------------------------
>> 
>> The description of what is added in this draft in the Security
>> Considerations section is good, but aren't there additional security
>> considerations (risks) with this addition?
> 
> Thanks for the review and question, see below.
> 
>> 
>> This document extends the LSP Ping and Traceroute mechanisms to
>>  discover and exercise ECMP paths when an LSP uses ELI/EL in the label
>>  stack.  Additional processing is required for responder and initiator
>>  nodes.  The responder node that pushes ELI/EL will need to compute
>>  and return multipath data including associated EL.  The initiator
>>  node will need to store and handle both IP multipath and label
>>  multipath information, and include destination IP addresses and/or
>>  ELs in MPLS echo request packets as well as in multipath information
>>  sent to downstream nodes. 
>> 
>> BTW, the above is a nice description that would have been nice to see
>> sooner in the text.
>> The draft then says:
>> 
>> This document does not itself introduce
>>  any new security considerations.
>> 
>> Isn't there anything that should be said about risks with the extended
>> capabilities to discover and exercise ECMP paths?  Does this help network
>> reconnaissance?  Does it help attackers to have this additional
>> information?  If it doesn't, please explain why and that will clear up
>> this discuss or adding text would be good.
> 
> I think that sentence oversimplifies a bit. Even the additional processing can result in security considerations, although in this case it is quite incremental on top of the baseline existing processing of LSP Ping. We can clarify a bit.
> 
> Further, RFC 4379 already allows for a faster network reconnaissance with the DDMAP and tree trace functionality as compared to brute force exercising all paths, but it does not mention it. This does the same also for when there’s ELI/EL.
> 
> It really does not help attackers any other way.
> 
> We will add some text covering these two things.
> 
> Thanks!
> 
> — Carlos.
> 
>> Thanks.
>