I've read the draft, and find it to be very high quality and very clear. The one comment I have regarding pCount, is in regards to processing received pCount=0 announcements.
I believe the concerns regarding "AS-path cheating" to attract traffic, by using pCount=0, could be addressed with some special handling. Basically, when receiving pCount=0 at the top of the stack (most recent addition, by one's peer), checking the next-hop to ensure it satisfies "three-routing" requirements, i.e. that the next hop be something other than the neighbor's IP address, is sufficient. The only other suggestion is related to the number of signature blocks. I agree that support for two is needed at a minimum. I am not entirely sure that restricting it to two is necessary, but haven't thought through the scenarios here. Perhaps "one or more" rather than "one or two"? Has there been any thought to use of a cryptographically signed "Expire Time" (which can be sent and updated as a keep-alive/add-time-to-the-meter mechanism), and then having the blocks refer to the Expire Time by reference (and have the reference internally by pointer, originally matching a cryptographic hash on the first received timer, whose pointed-to value gets updated)? This reduces the "beacon" issue to updating a single value, and limits the playback to the interval during which the original Expire Time exists. Newer updates would refer to the latest cryptographic hash of the last sent Expire Time (update). It becomes a chaining exercise in a state-ful environment... Brian On Tue, Nov 1, 2011 at 12:59 PM, Matt Lepinski <mlepin...@bbn.com> wrote: > I have updated the BGPSEC protocol specification. > > At the SIDR meeting in Quebec, there was significant discussion about how > BGPSEC could provide security of the AS-PATH attribute while still > accommodating the needs of route servers that participate in BGP, but do not > wish to increase the length of the AS-PATH attribute. The -01 version of the > draft contains a mechanism (a field called pCount) which attempts to > address this issue by having route servers create BGPSEC signatures without > increasing the effective length of the AS-PATH attribute. I would greatly > appreciate comments on this mechanism and whether it adequately addresses > the issues raised at the last SIDR meeting and subsequently discussed on the > list. > > There was has also been significant discussion on the SIDR list of the > "Expire TIme" field in BGPSEC and the associated "Beacon-ing" (that is, > periodic re-advertisement of a prefix with a new signature and a new Expire > Time) as a mechanism to address replay attacks (as well as attacks where a > malicious peer fails to propagate the withdrawal of a route). My > understanding is that the consensus of the working group was that the > current Expire Time mechanism is reasonable as long as re-advertisement is > only required at the origin AS (and not at intermediate ASes). The current > -01 version of the draft attempts to reflect that consensus. > > Finally, there are a number of small editorial changes that I believe will > improve the clarity of the draft. Thanks again to everyone who has reviewed > the document, feedback on how the text could be made more easily > understandable is especially welcome. > > - Matt Lepinski > > > > > On 10/31/2011 3:38 PM, internet-dra...@ietf.org wrote: >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. This draft is a work item of the Secure Inter-Domain Routing >> Working Group of the IETF. >> >> Title : BGPSEC Protocol Specification >> Author(s) : Matthew Lepinski >> Filename : draft-ietf-sidr-bgpsec-protocol-01.txt >> Pages : 28 >> Date : 2011-10-31 >> >> This document describes BGPSEC, an extension to the Border Gateway >> Protocol (BGP) that provides security for the AS-PATH attribute in >> BGP update messages. BGPSEC is implemented via a new optional non- >> transitive BGP path attribute that carries a digital signature >> produced by each autonomous system on the AS-PATH. >> >> >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-sidr-bgpsec-protocol-01.txt >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> This Internet-Draft can be retrieved at: >> ftp://ftp.ietf.org/internet-drafts/draft-ietf-sidr-bgpsec-protocol-01.txt >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr >> > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
