Hi Ben, Apologies and especially to Daniel. > I don't see any responses to this review in the mailarchive. It looks like > it was even sent before the end of the IETF LC, so I'm pretty surprised > that there was no response. (I'm particularly interested in the last > question about the security considerations.) I think I read as far as... > Reviewer: Daniel Migault > Review result: Ready > > Hi, > > Review result: Ready ...and stopped. No issues, no nits, come back to the clarifications later. Sigh. Well, it is "later" so I'm on target. > I 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. However, in > this case these comments mostly reflect some question to clarify my own > understanding. Document authors, document editors, and WG chairs should treat > these comments just like any other IETF Last Call comments. > > Yours, > Daniel > > Just to clarify my understanding of Fig 1. BGP usually selects the best route, > so if AS1-AS2 is the best, none of the traffic will go through AS3. However > even in this configuration AS2 will select one of the GW and all traffic will > go only to one of the GW1 or GW2. The Add-Path might be able to distinguishes > between AS1-AS2 and AS3 but AS1-AS2 cannot be subdivided between two paths one > that would terminates in GW1 and another that would terminates at GW2. Right. What you stated is exactly the problem that we needed to resolve with this document. The document explains the problem. And, as you note (and the draft notes) Add-Path is only a solution in some cases, but not in general. > I am not sure following acronyms may be expanded as well as AFI/SAFI being > described with text as opposed to their values. I let you decide whether that > is needed or not. You're right. Mysteriously, AFI/SAFI are not listed as well-known at https://www.rfc-editor.org/materials/abbrev.expansion.txt 1. I'll update the draft 2. I'll ping the RPC > OLD: > An IPv4 or IPv6 NLRI containing one of the GW's loopback addresses > (that is, with an AFI/SAFI pair that is one of 1/1, 2/1, 1/4, or > 2/4). > > NEW > An IPv4 or IPv6 Network Layer Reachability Information (NLRI) [RFC4760] > containing one of the GW's loopback addresses (that is, with an Address Family > Number (AFI)/ Subsequent Address Family (SAFI) pair that is one of IPv4/NLRI > used for unicast forwarding (1/1), IPv6/NLRI used for unicast forwarding > (2/1), IPv4/NLRI with MPLS Labels (1/4), or IPv6/NLRI with MPLS Labels (2/4)). OK. Something like that will go in. > Security consideration: > > When the information is shared between the domains, I am wondering if the > information is encrypted or if the communication appears in clear text. If no > encryption is used, that information is actually not limited to the two domains > but to anyone on path can read it. If that is the case, information provided by > the Egress SR domain to the Ingress SR Domain seems to me transiting through > the backbone which makes the information pretty much public. I am wondering if > I am missing something. Maybe the current text in Section 8 is not clear enough on this point. Or rather, it in oblique in its approach to this issue. You are right on exactly this. It is the same problem as in a VPN - information about the sites at the edge of the network is carried across the network in BGP messages. Those messages could reveal the information unless they are protected. BGP is (of course) carried over TCP, and TCP can be protected. This is being clarified in answer to one of the points John Scudder raised in his review. Thanks, Adrian -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
