On 12/13/16, 7:26 AM, "Sriram, Kotikalapudi (Fed)" <[email protected]> wrote:
> [Sriram-3] I understand now your main comment about confederation. I think > there are > two ways to address it (of course I hope other people chime in as well): > > Choice A: The pCount = 0 solution that you have suggested. > > But I feel that this is somewhat a cosmetic solution. In your example, it can > be perhaps > questioned whether the signature with pCount = 0 from AS2 to AS65001 does > actually fit > the security guarantee from Section 8.1 that you’ve cited. Because AS2 (the > AS with the > public ASN) did not produce that signature directly. Instead AS65001 played > proxy for > AS2 -- which is of course part of the original solution anyway. So we may > consider choice > B below. Well, the PE with both AS2 and AS65001 *is* both AS2 *and* AS65001…so I don’t see it as a proxy. > Choice B: Include a caveat to the statement in Section 8.1. For instance, we > modify it as > follows: > > For each AS in the path, a BGPsec speaker authorized by the holder > of the AS number intentionally chose (in accordance with local > policy) to propagate the route advertisement to the subsequent AS > in the path (except for a minor caveat that applies in the case of > BGPsec speakers > in a confederation). The caveat applies because a BGPsec speaker > in a confederation-member AS can be a proxy receiver and signer for the > public AS > (identified by the public AS number of the confederation). Therefore, a > signature that > appears to > correspond to an AS with the public AS number may actually > be proxy produced by a member AS that has an internal AS number > not matching the public AS number. The confederation-member ASes > are cognizant of this and hence it poses no security concern > within the confederation, and it is transparent to ASes outside > the confederation (see Section 4.3). > > [Sriram-3] Do you feel Choice B makes sense? Personally, I don’t like Choice B because it reads: “we guarantee X, except in a scenario where the signatures are not what they seem”… It doesn’t give me a warm a fuzzy feeling, especially when we’re talking about a security-related document. This is where I would like the Chairs/rest of the WG to pitch in. … > [Sriram-3] Perhaps I should wait for some more IESG LC reviews to roll in > before I include > this set of changes and those from Russ (Gen-ART) and Nevil (OPS-DIR)? Please > advise. The IETF LC ends tomorrow. Include the changes with anything you receive by tomorrow. Thanks! Alvaro.
_______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
