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

From: "Kathleen Moriarty" <[email-masked]>
Date: Tue, 29 Sep 2015 08:15:03 -0700

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.

---

From: Mach Chen <[email-masked]>
Date: Wed, 30 Sep 2015 02:28:02 +0000

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.

Best regards,
Mach 

> -----Original Message-----
> From: Kathleen Moriarty [mailto:[email-masked]]
> Sent: Tuesday, September 29, 2015 11:15 PM
> To: The IESG
> Cc: [email-masked];
> [email-masked]; [email-masked];
> [email-masked]; [email-masked];
> [email-masked]
> Subject: Kathleen Moriarty's Discuss on
> draft-ietf-mpls-lsp-ping-reply-mode-simple-04: (with 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.)
> 
> 
> 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
> 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.
> 
> 
>

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 29 Sep 2015 22:39:13 -0400

Hi,

Thanks for suggesting text quickly to address this.  Inline

Sent from my iPhone

> On Sep 29, 2015, at 10:28 PM, Mach Chen <[email-masked]> wrote:
> 
> Hi Kathleen,
> 

If the message is not encrypted, this content is still exposed potentially, right?  This helps, but also mentioning lack of confidentiality protection might be helpful too.

Thank you,
Kathleen

---

From: Mach Chen <[email-masked]>
Date: Wed, 30 Sep 2015 03:13:06 +0000

Hi Kathleen,

Thanks for your prompt response!

Please see my reply inline...

> From: Kathleen Moriarty [mailto:[email-masked]]
> Sent: Wednesday, September 30, 2015 10:39 AM
> To: Mach Chen
> Cc: The IESG; [email-masked];
> Subject: Re: Kathleen Moriarty's Discuss on
> > 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.
"

Best regards,
Mach

> >> [email-masked];
> >> [email-masked];
> >> [email-masked];
> >> [email-masked]; [email-masked]
> >> 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
> >> 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
> >> since now it's possible to gather the path information from the new feature.
> >

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 30 Sep 2015 12:12:27 -0400

>    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,
Kathleen