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

[Kathleen Moriarty <[e-mail]>]

On Tue, Sep 29, 2015 at 11:13 PM, Mach Chen <[e-mail]> wrote:
> Hi Kathleen,
>
> Thanks for your prompt response!
>
> Please see my reply inline...
>
>> -----Original Message-----
>> From: Kathleen Moriarty [mailto:[e-mail]]
>> Sent: Wednesday, September 30, 2015 10:39 AM
>> To: Mach Chen
>> Cc: The IESG; [e-mail];
>> [e-mail]; [e-mail];
>> [e-mail]; [e-mail];
>> [e-mail]
>> Subject: Re: Kathleen Moriarty's Discuss on
>> draft-ietf-mpls-lsp-ping-reply-mode-simple-04: (with DISCUSS)
>>
>> Hi,
>>
>> Thanks for suggesting text quickly to address this.  Inline
>>
>> Sent from my iPhone
>>
>> > On Sep 29, 2015, at 10:28 PM, Mach Chen <[e-mail]>
>> wrote:
>> >
>> > Hi Kathleen,
>> >
>> > Thanks for reviewing the draft and the suggestion!
>> >
>> > Regarding the DISCUSS, how about the following update?
>> >
>> > OLD:
>> > Beyond those specified in [RFC4379] and [RFC7110], there are no further
>> security measures required.
>> >
>> > NEW:
>> > Those security considerations specified in [RFC4379] and [RFC7110] apply for
>> this document.
>> > In addition, this document introduces the Reply Mode Order TLV. It provides a
>> new way for an unauthorized source to gather more network information,
>> especially the potential return path(s) information of an LSP. To protect against
>> unauthorized sources using MPLS echo request messages with the Reply Mode
>> Order TLV to obtain network information, similar to [RFC4379], it is
>> RECOMMENDED that implementations provide a means of checking the source
>> addresses of MPLS echo request messages against an access list before
>> accepting the message.
>>
>> If the message is not encrypted, this content is still exposed potentially, right?
>
> Yes, but it is exposed within the MPLS domain.
>
>> This helps, but also mentioning lack of confidentiality protection might be
>> helpful too.
>
> I'm not sure whether this issue is specific to this document, seems this is a common issue for MPLS OAM and control plane.
>
> If this is a concern, how about adding the following text:
> "
> Another potential security issue is that the MPLS echo request and
>    reply messages are not encrypted, the content of the MPLS echo
>    request and reply messages may be potentially exposed. Although the
>    exposure is within the MPLS domain, if such exposure is a concern,
>    some encryption mechanisms may be employed.
> "

This additional text puts int he caveat that you are concerned with
and limits the scope to the MPLS domain, so I think that is helpful on
both fronts.  The two combined would cover any additional
considerations for this draft nicely, thank you.

Please let me know when the updated text has been incorporated and I will clear.

Thanks,
Kathleen
>
> Best regards,
> Mach
>
>>
>> Thank you,
>> Kathleen
>>
>> >
>> >
>> > Best regards,
>> > Mach
>> >
>> >
>> >> -----Original Message-----
>> >> From: Kathleen Moriarty [mailto:[e-mail]]
>> >> Sent: Tuesday, September 29, 2015 11:15 PM
>> >> To: The IESG
>> >> Cc: [e-mail];
>> >> [e-mail];
>> >> [e-mail];
>> >> [e-mail];
>> >> [e-mail]; [e-mail]
>> >> Subject: Kathleen Moriarty's Discuss on
>> >> draft-ietf-mpls-lsp-ping-reply-mode-simple-04: (with DISCUSS)
>> >>
>> >> Kathleen Moriarty has entered the following ballot position for
>> >> draft-ietf-mpls-lsp-ping-reply-mode-simple-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-lsp-ping-reply-mode-
>> >> simple/
>> >>
>> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> -
>> >> DISCUSS:
>> >> ---------------------------------------------------------------------
>> >> -
>> >>
>> >> This should be easy to resolve.  SInce this draft adds a new
>> >> capability to include the return path, this provides another attack
>> >> vector to observe path information that could be part of
>> >> reconnaissance gathering to later attack the network or path.  While
>> >> the referenced RFC4379 mentions the following in the security
>> considerations section:
>> >>
>> >>   The third is an
>> >>   unauthorized source using an LSP ping to obtain information about the
>> >>   network.
>> >>
>> >> The equivalent should be added for this new capability in this draft,
>> >> since now it's possible to gather the path information from the new feature.
>> >



-- 

Best regards,
Kathleen