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! > > > > Please see my response inline... > > > > > -----Original Message----- > > > From: Benjamin Kaduk [mailto:kaduk@xxxxxxx] > > > Sent: Sunday, January 27, 2019 5:17 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 > > > > > > 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:ietf-bounces@xxxxxxxx] On Behalf Of Linda > > > > > Dunbar > > > > > Sent: Wednesday, December 12, 2018 4:24 AM > > > > > To: secdir@xxxxxxxx > > > > > Cc: mpls@xxxxxxxx; > > > > > draft-ietf-mpls-lsp-ping-lag-multipath.all@xxxxxxxx; > > > > > ietf@xxxxxxxx > > > > > 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
