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

[Benjamin Kaduk <[e-mail]>]

On Mon, Feb 18, 2019 at 10:11:24AM +0000, Mach Chen wrote:
> 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!
> > >
> > >
> > > "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. 

Thanks!

> > 
> > > >
> > > > 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.

Given what I've seen so far, yes.  (I only skimmed the document as part of
this thread, and will do a full review as it comes up on an IESG telechat.)

-Benjamin