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

[Mach Chen <[e-mail]>]

Hi Christian,

Thanks for your prompt response!

We will update the draft as agreed.

Best regards,
Mach

> -----Original Message-----
> From: Christian Huitema [mailto:[e-mail]]
> Sent: Thursday, June 30, 2016 12:48 PM
> To: Mach Chen; [e-mail]; [e-mail];
> [e-mail]
> Subject: RE: SECDIR review of draft-ietf-pals-mpls-tp-pw-over-bidir-lsp-08
> 
> On Wednesday, June 29, 2016 7:39 PM, Mach Chen wrote:
> >
> > Hi Christian,
> >
> > Thanks for your review and comments!
> 
> You are welcome.
> 
> > Please see my replies inline...
> >
> > > -----Original Message-----
> > > From: Christian Huitema [mailto:[e-mail]]
> > > Sent: Thursday, June 30, 2016 6:57 AM
> > > To: [e-mail]; [e-mail];
> > > [e-mail]
> > > 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.
> > >
> > > 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.
> >
> > 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."
> 
> 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.
> 
> > > 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?
> 
> OK.
> 
> > > 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.
> >
> > 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
> 
>