Chris, Do you think the proposed receiver processing rules below are insufficient?
dougm ________________________________________ From: Highwayman [[email protected]] Sent: Thursday, July 28, 2011 11:31 AM To: Montgomery, Douglas Cc: Danny McPherson; sidr wg list Subject: Re: [sidr] pCNT & prepending It's not clear to me how the system is protected from some unscrupulous transit provider setting their AS's to zero width, in order to attract more traffic. Unless there is a side channel for ASN which may validly announce themselves in this way ? I agree that transparency is the minimum requirement. I do not, yet, discount the emotional demand for Route Server users to not be seen to be RS users. For many years we peered at LINX and, frankly, would not have dreamt of either using the RS, or be seen to be using it -- we were big boys -- notwithstanding, we peered openly... go figure :-) Chris -- Chris Hall. +44 7970 277 383 (iPhone) On 28 Jul 2011, at 11:11, "Montgomery, Douglas" <[email protected]> wrote: > Danny, > > Yes, that is certainly the idea if we agree to protect prepending (as opposed > to just avoiding multiple Sigs in the the presence of prepending). > > If we protect prepending, the pCNT must be carried in the protocol, covered > by the Sig and verified ... i.e., what you suggest below .. in validation. > > Note, that if you don't want to protect prepending ... only avoid repeating > sigs ..., then you don't have to carry pCNT in the protocol. Just update the > Sig verification algorithm treat sequences of repeated AS's as one. > > If we like the "translucent" approach to support RS, then we need to carry > pCNT in BGSSEC. You are right we do need enhanced receive/process rules > such as: > > 1. Only accept pCNT=0 from peers that are configured to be route servers. > > 2. Don't accept paths with multiple pCNT=0 entries in a row. > > Anyway, if we like this approach, we can talk the details of the receiving > rules / process rules to protect potential abuse. > > dougm > > Doug Montgomery - Manager Internet and Scalable Systems Research Group / > Information Technology Laboratory / NIST > ________________________________________ > From: [email protected] [[email protected]] On Behalf Of Danny > McPherson [[email protected]] > Sent: Thursday, July 28, 2011 11:02 AM > To: sidr wg list > Subject: [sidr] pCNT & prepending > > Doug et al, > I like the general objective of pCNT and this seems a good idea to me. My > only comment at the microphone was that if we add this for compression, then > validation should require that pCNT MUST be equal to the number of > _contiguous ASx appearances in the path (i.e., no more, no less, and only > contiguous). > > I do wonder if pCNT=0 for transparent route servers introduces the > opportunity for some sort of downgrade attack of sorts.. > > -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
