Re: [secdir] Secdir last call review of draft-ietf-mpls-lsp-ping-lag-multipath-05

[Mach Chen <[e-mail]>]

Hi Benjamin,

> -----Original Message-----
> From: Benjamin Kaduk [mailto:[e-mail]]
> Sent: Sunday, February 17, 2019 4:28 AM
> To: Mach Chen <[e-mail]>
> Cc: Linda Dunbar <[e-mail]>; [e-mail];
> [e-mail]; [e-mail];
> [e-mail]
> Subject: Re: [secdir] Secdir last call review of draft-ietf-mpls-lsp-ping-lag-
> multipath-05
> 
> Hi Mach,
> 
> My apologies as well for the delay.
> 
> On Thu, Feb 14, 2019 at 03:02:07AM +0000, Mach Chen wrote:
> > Hi Benjamin,
> >
> > Sorry for the delayed response!
> >
> > Please see my response inline...
> >
> > > -----Original Message-----
> > > From: Benjamin Kaduk [mailto:[e-mail]]
> > > Sent: Sunday, January 27, 2019 5:17 AM
> > > To: Mach Chen <[e-mail]>
> > > Cc: Linda Dunbar <[e-mail]>; [e-mail];
> > > [e-mail]; [e-mail];
> > > [e-mail]
> > > Subject: Re: [secdir] Secdir last call review of
> > > draft-ietf-mpls-lsp-ping-lag-
> > > multipath-05
> > >
> > > On Fri, Dec 14, 2018 at 02:11:21AM +0000, Mach Chen wrote:
> > > > Hi Linda,
> > > >
> > > > Thanks for the review!
> > > >
> > > > Some responses inline...
> > > >
> > > > > -----Original Message-----
> > > > > From: ietf [mailto:[e-mail]] On Behalf Of Linda
> > > > > Dunbar
> > > > > Sent: Wednesday, December 12, 2018 4:24 AM
> > > > > To: [e-mail]
> > > > > Cc: [e-mail];
> > > > > [e-mail];
> > > > > [e-mail]
> > > > > Subject: Secdir last call review of
> > > > > draft-ietf-mpls-lsp-ping-lag-multipath-05
> > > > >
> > > > > Reviewer: Linda Dunbar
> > > > > Review result: Ready
> > > > >
> > > > > 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 summary of the review is Ready with comment
> > > > >
> > > > > The described mechanism for LSP Multipath Ping is very clear.
> > > > > The Security Consideration re-uses the description of RFC8029,
> > > > > which is very comprehensive.
> > > > > It would be better if the draft describes how to prevent
> > > > > intermediate LSRs in between the Initiating LSR and Responding
> > > > > LSR from mis-using the detailed link information (e.g.
> > > > > forwarding to
> > > somewhere else).
> > > >
> > > > The Echo Request and Reply messages are directly exchanged between
> > > > the
> > > Initiating LSR and the Responding LSR, those intermediate LSRs just
> > > forward the messages as normal packets, they will not see the
> > > detailed link information unless if they inspect and do DPI on every
> > > packet forwarded by them.
> > > >
> > > > The detailed link information is supplied to the Initiating LSR
> > > > for using, the
> > > intermediate LSRs will not try to use it even if they received the
> > > information, because there is no corresponding Echo Request to the
> received Echo Reply.
> > >
> > > The intermediate LSRs still will have access to the plaintext
> > > information, even if in normal operation they do not need to act upon
> that information.
> > > Generally in this sort of situation we will either explicitly state
> > > that the intermediate nodes must be trusted to not abuse the
> > > information in question, or provide some mechanism for end-to-end
> > > confidentiality protection.
> >
> > "Intermediate nodes must be trusted to not abuse the information" is
> normally assumed. For the intermediate nodes, there is no different
> between the Echo Reply messages and any other data traffic, control
> messages. They just forward the Echo Reply messages as normal packets.  I
> am not sure it needs to explicitly state this.  Do you suggest to add such a
> statement in the security consideration section?
> 
> The concern is not about the normal operation, but rather about abnormal
> operation, e.g., if an intermediate node gets compromised by an attacker.
> We need to document the new abilities an attacker gets, when comparing
> the original case of "an attacker compromises an intermediate node that is
> using MPLS without this mechanism" to the new case of "an attacker
> compromises an intermediate node that is using MPLS with this mechanism".
> So, while I do suggest adding a statement to the security considerations
> section, the statement I want does not relate to the normal operation case
> (when intermediate nodes ignore the contents of the message).

OK, will add such a statement in the security considerations section. 

> 
> > >
> > > Also (noting that I only skimmed the document so this may not make
> > > sense), the security considerations seem to suggest using an IP ACL
> > > for determining which messages are trusted; IP ACLs are generally
> > > not recommended in favor of cryptographic mechanisms at this point.
> >
> > IP ACLs was introduced in RFC 8029 and is reused in this document,
> > it's
> 
> I did not find a clear and explicit declaration in RFC 8029 of the concept of an
> IP ACL; I assume you are referring to:
> 
>    To protect against unauthorized sources using MPLS echo request
>    messages to obtain network information, 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.

Yes, this is that I am referring to.

> 
> I do not think anyone is going to say "do not filter based on IP source
> address", but there would be general skepticism about relying upon it as a
> sole security mechanism.
> 
> > just one of the security mechanisms. This document is an extension to
> 
> (Could you remind me of the other mechanisms?  I don't think I have a good
> handle on them.)

You are right, for protecting against unauthorized sources, IP ACL is the only way proposed in RFC 8029 and this document. 

> 
> > RFC 8029, as stated in this document, all security considerations
> > defined in RFC 8029 apply to this document. Do you have any specific
> > suggestion to the current security consideration?
> 
> I am mostly just lamenting the state of affairs; this is a sufficiently
> incremental change that it is inappropriate to require dramatic changes in the
> security mechanisms.

I agree with you. Does it mean that you are OK with the current security considerations, given that a statement regarding the intermediate node's process will be added.

Best regards,
Mach

> 
> -Ben