Brian, Danny is talking about pfx-validate, which is not the same as BGPSEC.
--John On Nov 13, 2011, at 1:48 AM, Brian Dickson wrote: > I think the current design of BGPsec as memorialized (love that word) in the > draft-ietf-sidr-bgpsec-protocol would need to be tweaked to handle this. > > I also believe that the result of the proposed tweak, will be a cleaner design > which is easier to implement and verify, as well as not incurring significant > operational cost in terms of signatures. > > Local origination SHOULD occur within an AS on a permanent > basis, and only the announcements from the actual originating router need > to have unique signatures, regardless of whether they are iBGP or eBGP. > > (Crypto geeks might suggest adding a random "nonce" to make the signature > a little harder to crack, since very little on the signature material > will change > over time - but that is another discussion.) > > Here is the tweak: > > Sequence of Octets to be Signed > +---------------------------------------+ > | Expire Time (8 octets) | > +---------------------------------------+ > | Origin AS Number (4 octets) | > +---------------------------------------+ > | Algorithm Suite Identifier (1 octet) | > +---------------------------------------+ > | NLRI Length (1 octet) | > +---------------------------------------+ > | NLRI Prefix (variable) | > +---------------------------------------+ > > The "Target AS" and "pCount" need to be added, meaning the minimum > number of signatures > changes to "one origin" and "one propagation" signature. > > For iBGP within the originating AS, the signature would be "Target AS > == origin AS", and "pCount == 0". > > For eBGP, it would be what you expect, "Target AS == neighbor", "pCount > 0". > > I think that's all that is needed, and the rest of the validation > logic in the -protocol doc remain good, > the -ops-reqs doc allows validation for local AS, and pfx-validate also works. > > Any detail or logic errors in the above can be attributed to not > enough caffeine... The gist of the above > should be solid enough, though. > > Brian > > On Sat, Nov 12, 2011 at 11:54 AM, Danny McPherson <[email protected]> wrote: >> >> My read of the current draft suggests that if there's a route generated by >> the >> local AS in BGP it could never have a "Valid" state, and by definition >> would >> either posses a "Not found" or "Invalid" state -- even though the local >> AS may well have a "ROA" and reside in the mapping table as well(!). >> I do not believe the current text is Section 5 is sufficient to address this >> case, >> specifically with either this: >> "Considering invalid routes for BGP decision process is >> a pure local policy matter and should be done with utmost care." >> or this: >> "In some cases (particularly when the selection algorithm is >> influenced by the adjustment of a route property that is not >> propagated into IBGP) it could be necessary for routing >> correctness to propagate the validation state to the IBGP >> peer. This can be accomplished on the sending side by setting >> a community or extended community based on the validation >> state, and on the receiving side by matching the (extended) >> community and setting the validation state." >> I could think of a number of way to address this, but for there to exist >> the >> possibility that an internally generated prefix (for which a ROA may well >> exists) >> could NEVER have a "Valid" state needs to be corrected. >> Also, S 4: s/to rest of the network/to the rest of the network/ >> Thanks, >> -danny >> >> _______________________________________________ >> sidr mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/sidr >> >> > _______________________________________________ > sidr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/sidr _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
