At Mon, 17 Mar 2014 00:40:30 +0100, Matthias Waehlisch wrote:
>
> Sorry for the late reply ...
Mine is even later, as I was mostly offline for more than a week.
> Just to double check, because the term "duplicate" is not very clear
> in this context - at least to me. In contrast to RFC 6810, in RFC
> 6810-bis a Router Key PDU contains a list of ASNs. The received PDU may
> differ even though parts of the content are duplicates.
>
> RFC 6810 says "identical to one it already has active", which means
> that we are checking pieces of content. For example, the router receives
> Router Key PDU with ASNs {10,20,30} and later the 'same' PDU but with
> ASNs {10,20}. I would consider this as a duplicate. However, in this
> case the ordering doesn't help to apply binary string comparison.
This is a can of worms. Thank you for being polite about it. :)
At this point I think the simplest solution would be to change the
format of the proposed Router Key PDU so that it contains exactly one
ASN. In the rare cases (router operators, sanity check this, please)
where there is a need for multiple ASNs to share the same key, the
cache would just issue multiple Router Key PDUs, one for each ASN.
This approach is a bit verbose in the multi-ASN case, but has
trivially simple protocol semantics.
An alternative would be to require the cache to withdraw <K,10,20,30>
then announce <K,10,20>; in this case, "duplicate" would be defined
solely by the key.
My preference for the first approach is based on the assumption that
this is a rare case, therefore not worth optimizing at the expense of
additional protocol complexity. In particular, I would really prefer
to avoid adding code paths that will almost never be executed into a
security protocol.
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
