On Mon, Feb 18, 2019 at 10:11:24AM +0000, Mach Chen wrote: > Hi Benjamin, > > > -----Original Message----- > > From: Benjamin Kaduk [mailto:kaduk@xxxxxxx] > > Sent: Sunday, February 17, 2019 4:28 AM > > To: Mach Chen <mach.chen@xxxxxxxxxx> > > Cc: Linda Dunbar <linda.dunbar@xxxxxxxxxx>; secdir@xxxxxxxx; > > mpls@xxxxxxxx; draft-ietf-mpls-lsp-ping-lag-multipath.all@xxxxxxxx; > > ietf@xxxxxxxx > > 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
