Subject: [secdir] SECDIR review of draft-ietf-pals-mpls-tp-pw-over-bidir-lsp-08

From: "Christian Huitema" <[email-masked]>
Date: Wed, 29 Jun 2016 15:57:27 -0700

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 primarily for the benefit of the 
security area directors.  Document editors and WG chairs should treat 
these comments just like any other last call comments.

The document is ready with 2 nits.

The document specifies an extension to the Label Distribution Protocol (LDP,
RFC 5036) to provide bindings between Pseudo Wires (PW) and Label Switch
Paths (LSP) established over MPLS-TP (RFC6773). The goal is to ensure that
both directions of the PW are mapped to the same LSP, and thus avoid
asymmetric routing. The document specifies additional LDP extensions to
carry the required information.

The security section acknowledges one concern: that attackers could misuse
the option to force a pseudo wire through an unnatural path, either as a
denial of service attack, or to facilitate traffic interception. The
proposed mitigation to that attack is essentially "careful Implementation",
i.e. only accept binding requests where the LSP endpoints match the PW
endpoints. Should a mismatch occur, I assume that the endpoint will reject
the proposed binding, as specified in section 5, PSN Binding Operation for
MS-PW. 

And here is one nit: I would like to see the verification behavior specified
as part of the binding operations, rather than merely mentioned in the
security section. Also, is there a specific error case for the security
failure, or just the generic error message? 

The next nit is tied to the general security profile of LDP, which is
specified to use TCP(MD5). There is no expectation of privacy for LDP data.
I am not sure that the new extensions increase the "privacy surface" of LDP.
They do carry global identifiers of source and destination, and inform about
the path of packets between these destinations, and it seems that
adversaries could use that for monitoring and targeting purposes. But it is
possible that the information is already present in LDP. A note to that
effect in the security section would have been nice.

-- Christian Huitema

---

From: Mach Chen <[email-masked]>
Date: Thu, 30 Jun 2016 02:39:20 +0000

Hi Christian,

Thanks for your review and comments!

Please see my replies inline...

> -----Original Message-----
> From: Christian Huitema [mailto:[email-masked]]
> Sent: Thursday, June 30, 2016 6:57 AM
> To: [email-masked]; [email-masked];
> [email-masked]
> Subject: SECDIR review of draft-ietf-pals-mpls-tp-pw-over-bidir-lsp-08
> 
> 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 primarily for the benefit of the security area directors.
> Document editors and WG chairs should treat these comments just like any
> other last call comments.
> 
> asymmetric routing. The document specifies additional LDP extensions to carry
> the required information.
> 
> the option to force a pseudo wire through an unnatural path, either as a denial
> of service attack, or to facilitate traffic interception. The proposed mitigation to
> that attack is essentially "careful Implementation", i.e. only accept binding
> requests where the LSP endpoints match the PW endpoints. Should a mismatch
> occur, I assume that the endpoint will reject the proposed binding, as specified
> in section 5, PSN Binding Operation for MS-PW.
> 
> And here is one nit: I would like to see the verification behavior specified as part
> of the binding operations, rather than merely mentioned in the security section.

OK, how about adding the following text?

For SS-PW:
"In addition, if the received PSN tunnel/LSP end points do not match the PW end points, PE2 MUST reply with a Label Release message with status code set to "Reject - unable to use the suggested tunnel/LSPs" (TBD4) and the received PSN Tunnel Binding TLV MUST also be carried."

For MS-PW:
"In addition, if the received PSN tunnel/LSP end points do not match the PW Segment end points, the receiving PE MUST reply with a Label Release message with status code set to "Reject - unable to use the suggested tunnel/LSPs" (TBD4) and the received PSN Tunnel Binding TLV MUST also be carried."

> Also, is there a specific error case for the security failure, or just the generic
> error message?

Since this is a potential attack, seems it is safer not to deliver more specific reason to the attacker. I think the generic error message is sufficient. How do you think?

> 
> The next nit is tied to the general security profile of LDP, which is specified to
> use TCP(MD5). There is no expectation of privacy for LDP data.
> They do carry global identifiers of source and destination, and inform about the
> path of packets between these destinations, and it seems that adversaries
> could use that for monitoring and targeting purposes. But it is possible that the
> information is already present in LDP. A note to that effect in the security
> section would have been nice.

Actually, the information is already present in both sides of the LDP session, otherwise the receiving PE cannot bind/match/compare those IDs. IMHO, this new extension does not increase the "privacy surface" of LDP. 

The aforementioned information is not special/different from other information (e.g., the FECs, Labels, PE addresses, etc.) that are already transmitted over the LDP session. I'm incline to not add extra text here if you are OK with it.

Best regards,
Mach

---

From: "Christian Huitema" <[email-masked]>
Date: Wed, 29 Jun 2016 21:48:24 -0700

> Thanks for your review and comments!

You are welcome.
 
> > I have reviewed this document as part of the security directorate's
ongoing
> denial
> > And here is one nit: I would like to see the verification behavior
specified as
> part
> "In addition, if the received PSN tunnel/LSP end points do not match the
PW
> end points, PE2 MUST reply with a Label Release message with status code
set
> to "Reject - unable to use the suggested tunnel/LSPs" (TBD4) and the
received
> PSN Tunnel Binding TLV MUST also be carried."

Yes.

> For MS-PW:
> "In addition, if the received PSN tunnel/LSP end points do not match the
PW
> Segment end points, the receiving PE MUST reply with a Label Release
> message with status code set to "Reject - unable to use the suggested
> tunnel/LSPs" (TBD4) and the received PSN Tunnel Binding TLV MUST also be
> carried."

Yes, that works.

> Since this is a potential attack, seems it is safer not to deliver more
specific
> reason to the attacker. I think the generic error message is sufficient.
How do
> you think?

OK.

> > The next nit is tied to the general security profile of LDP, which is
specified to
> the
> > could use that for monitoring and targeting purposes. But it is possible
that
> the
> Actually, the information is already present in both sides of the LDP
session,
> otherwise the receiving PE cannot bind/match/compare those IDs. IMHO, this
> new extension does not increase the "privacy surface" of LDP.
> 
> The aforementioned information is not special/different from other
> information (e.g., the FECs, Labels, PE addresses, etc.) that are already
> transmitted over the LDP session. I'm incline to not add extra text here
if you
> are OK with it.

If you do not actually increase the privacy surface, then yes, that's OK. 

-- Christian Huitema

---

From: Mach Chen <[email-masked]>
Date: Thu, 30 Jun 2016 06:04:37 +0000

Hi Christian,

Thanks for your prompt response!

We will update the draft as agreed.

Best regards,
Mach

> Sent: Thursday, June 30, 2016 12:48 PM
> To: Mach Chen; [email-masked]; [email-masked];
> Subject: RE: SECDIR review of draft-ietf-pals-mpls-tp-pw-over-bidir-lsp-08
> 
> > > Subject: SECDIR review of
> > > draft-ietf-pals-mpls-tp-pw-over-bidir-lsp-08
> > >
> > > effort to review all IETF documents being processed by the IESG.
> > > These comments were written primarily for the benefit of the
> > > security area
> > directors.
> > > Document editors and WG chairs should treat these comments just like
> > > any other last call comments.
> > >
> > > The document specifies an extension to the Label Distribution
> > > Protocol
> (LDP,
> > > RFC 5036) to provide bindings between Pseudo Wires (PW) and Label
> > > Switch Paths (LSP) established over MPLS-TP (RFC6773). The goal is
> > > to ensure
> that
> > > of service attack, or to facilitate traffic interception. The
> > > proposed
> > mitigation to
> > > that attack is essentially "careful Implementation", i.e. only
> > > accept
> binding
> > > occur, I assume that the endpoint will reject the proposed binding,
> > > as
> > specified
> > > of the binding operations, rather than merely mentioned in the
> > > security
> > section.
> >
> > tunnel/LSPs" (TBD4) and the received PSN Tunnel Binding TLV MUST also
> > be carried."
> 
> Yes, that works.
> 
> > > Also, is there a specific error case for the security failure, or
> > > just
> the generic
> > > error message?
> >
> > > I am not sure that the new extensions increase the "privacy surface"
> > > of
> LDP.
> > > They do carry global identifiers of source and destination, and
> > > inform
> about
> > the
> > otherwise the receiving PE cannot bind/match/compare those IDs. IMHO,
> > this new extension does not increase the "privacy surface" of LDP.
> >
> > information (e.g., the FECs, Labels, PE addresses, etc.) that are
> > already transmitted over the LDP session. I'm incline to not add extra
> > text here
> if you
> > are OK with it.
>

---

From: "Andrew G. Malis" <[email-masked]>
Date: Thu, 30 Jun 2016 13:10:15 -0400

Mach,

You should wait for Deborah’s go-ahead before doing an update, I think that
she'll prefer that the update occur following the end of IETF last call.

Thanks,
Andy

On Thu, Jun 30, 2016 at 2:04 AM, Mach Chen <[email-masked]> wrote:

> > Subject: RE: SECDIR review of
> > > reason to the attacker. I think the generic error message is sufficient
>

---

From: Mach Chen <[email-masked]>
Date: Fri, 1 Jul 2016 00:48:26 +0000

Hi Andy,

Thanks for your guidance!

Yes, that’s the plan.

Best regards,
Mach

From: Andrew G. Malis [mailto:[email-masked]]
Sent: Friday, July 01, 2016 1:10 AM
To: Mach Chen
Cc: Christian Huitema; [email-masked]; [email-masked]; [email-masked]; BRUNGARD, DEBORAH A (ATTLABS)
Subject: Re: SECDIR review of draft-ietf-pals-mpls-tp-pw-over-bidir-lsp-08

Mach,

You should wait for Deborah’s go-ahead before doing an update, I think that she'll prefer that the update occur following the end of IETF last call.

Thanks,
Andy

On Thu, Jun 30, 2016 at 2:04 AM, Mach Chen <[email-masked]<mailto:[email-masked]>> wrote:
Hi Christian,

Best regards,
Mach

> From: Christian Huitema [mailto:[email-masked]<mailto:[email-masked]>]
> To: Mach Chen; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>;
> [email-masked]<mailto:[email-masked]>
> > > From: Christian Huitema [mailto:[email-masked]<mailto:[email-masked]>]
> > > To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>;
> > > [email-masked]<mailto:[email-masked]>