I don't think there is a bug. It seems to me that the solution as written now does indeed work if it can be assumed that every border router within a confed knows which peers are confed-EBGP peers and which peers are regular (external to confed) EBGP peers. That seems to be a necessary assumption anyway. (The modifications you propose also assume this.)
Let us consider this example: ----(B1----B2)----(B3----B4)----(B5----B6)----> ---------AS1------------AS2------------AS3--------> where AS1, AS2 and AS3 form a confed, and the update is propagating from left to right; AS1 is the entry AS; B1, B2 are border routers in AS1; B3, B4 are border routers in AS2; B5, B6 are border routers in AS3. When B1 gets an update, it propagates it to B2 without adding a new signature. B2 looks at the signatures backwards starting from the most recently added AS. If the confed-entry flag is not set by any preceding AS (as expected at B2 in this example), then B2 sets the flag, adds AS1’s signature and forwards the update to B3. B3 propagates the update to B4 (w/o adding a new signature). B4 does the same check as B2 did. B4 finds a flag already set (by AS1). So B4 simply adds AS2’s signature and propagates to B5. B6 happily strips all the confed internal signatures when it propagates the update to a regular (external to confed) EBGP peer. One special case is when the prefix is originated from within AS1 by B1. It seems that this case can be handled easily enough as well. B1 originates and sends the update without any Signature-list Block to B2. B2 sees no prior confed-entry flag, so it sets the flag, signs and propagates the prefix update to B3. So it all works correctly! Right? Please let me know if I am missing something. Thanks. Sriram ________________________________________ From: sidr-boun...@ietf.org [sidr-boun...@ietf.org] On Behalf Of John G. Scudder [j...@juniper.net] Sent: Wednesday, Aonfeds bug, with fix Randy, Sandy and I realized there is a problem with confeds. As written right now, the entering-the-confed marker is applied by the first router sending the route across an internal-to-the-confed boundary (let's call this router R). It can't be applied by the external peer router sending it to the confed in EBGP, since it has no clue (that's the nature of a confed), and it can't be applied by the border router within the confed (called router B) that's receiving it from that external peer, since it doesn't apply a signature (we only do that when sending routes across EBGP, or confed-EBGP). So, how does router R figure out it should apply the marker? In short, it can't. After discussing a few possible solutions, we came up with two alternatives: Have router B do the AS aliasing hack, i.e. sign to itself with pcount=0, and apply the mark on that signature. Equivalently, we could invent some new thing to go into the signatures that has the semantics of "this is a confed entry marker". ugust 01, 2012 8:18 PM To: sidr wg list Subject: [sidr] bgpsec c --John _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
