Correct, yes, I understand. My point is, that because of the inter-relatedness of the various SIDR documents, and because presumably the bgpsec-protocol document is not set in stone, the issues raised in other documents (in SIDR) can be considered as creating requirements to the protocol document.
As in, by making changes to the protocol (and necessarily the protocol draft), the issues elsewhere can be designed away and made moot. It is taking a holistic approach to the set of SIDR documents rather than documenting around an existing pre-standards bgpsec implementation. I humbly suggest that the authors of the other documents take a closer look at things I suggest, and perhaps voice them as concerns in the -protocol discussion, as relates to the overall design and in particular their own documents. Some see the glass as half-full, some as half-empty. I see the glass as too big. :-) Brian On Sun, Nov 13, 2011 at 3:12 AM, John Scudder <[email protected]> wrote: > 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
