At Fri, 7 Mar 2014 12:37:19 +0000, Matthias Waehlisch wrote: > On Fri, 7 Mar 2014, Rob Austein wrote: > > > but speaking on my own behalf as a implementer: if we define a > > canonical order, comparing two PDUs is a simple binary string > > comparison. If we don't define a canonical order, comparison is more > > complicated, hence more error-prone. > > > It's probably a shift of the "complexity" ... but I agree that it > simplifies the router part.
Not really more complicated for the cache. I'm holding this router certificate with an RFC 3779 ASIdentifiers extension and need to convert that certificate into a Router Key PDU. Turns out the ASIdentifiers extension already lists the ASNs in the canonical order, so I don't even have to sort it, in fact I'd have to work harder to put the ASNs in any other order. Sorting simplifies things in the cache too: stripping out all the PKI glorp can result in apparent duplicates in the stripped data, which my server is required to remove when constructing the feed my server gives to the router. At least in my implementation, having a single canonical form for the PDU simplifies this process, which is why I'm likely to implement it this way whether required to do so or not. > What happens if the ASNs are not in order (for some strange bug > reason)? It wouldn't harm the router? Point. So maybe caches MUST generate the canonical format but routers MAY skip checking to see whether the cache goofed this up? > > Given that the rpki-rtr protocol requires duplicate elimination, we do > > need to perform such comparisons, so making them as simple as possible > > seems advisable. > > > I suppose this requires an update of the duplicate description > (similar text of Section 5.6 in Section 5.10, and update Section 11, no > 11). Or consolidate the discussion of duplicate PDUs somewhere else in the document, but yes, we need to nail that down. _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
