I think we would all benefit from your offer to survey the RS community to see if solutions that did not effect PATH_LENGTH but do make the RS AS# visible somewhere in the protocol (we can quibble about the syntax of carrying that in AS_PATH vs PATH_SIGs later).
If one requires dropping routes with pCNT=0 from peers that are not administratively configured to be route servers, then allowing a unscrupulous transit provider to propogate that, now requires collusion between two AS's. There are other issues that come up if we consider those scenarios. One could think of having RS's somehow announce/declare themselves (e.g., an RPKI object/flag) ... But I will point out that if I am unscrupulous I will just announce myself and proceed. Anyway, again ... Let's get the requirement right before we talk about the encoding / mechanisms - you offer to survey if "translucent" supports the use case / business model of the RS community is an important step towards getting the requirement right. Dougm On 7/28/11 11:31 AM, "Highwayman" <[email protected]> wrote: >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 _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
