Re: [sidr] pCNT & prepending

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: sidr-bounces@ietf.org [sidr-bounces@ietf.org] On Behalf Of Danny McPherson [danny@tcb.net]
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
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr