Re: Last Call: <draft-ietf-sidr-rpki-rtr-19.txt> (The RPKI/Router Protocol) to Proposed Standard

[Terry Manderson <[e-mail]>]

On 28/01/12 3:02 PM, "Rob Austein" <[e-mail]> wrote:

> At Wed, 21 Dec 2011 17:43:23 -0800, Terry Manderson wrote:
>>
>> Apologies for my lack of attention to date on this topic, so speaking only
>> for myself here.
>
> Similar apologies for not having answered this more promptly.  Somehow
> we missed seeing this until our AD asked us about it.
>
> Please see draft-ietf-sidr-rpki-rtr-25, just posted, which we hope
> addresses most of your concerns (there are a few points on which I
> think we're just going to have to agree to disagree).

I will read -25 soon and raise any concerns should they remain.

>
[..]

> RADIUS doesn't have a bulk transfer operation, and bulk transfer of
> data is the main task of this protocol, particularly at start-up.

Is that function of the protocol now highlighted in -25?

>
> You are certainly entitled to your opinion, but it comes a bit late.
> This work was done in the public view, with regular progress reports
> to the SIDR WG, and we have multiple interoperable implementations
> including several of the major router vendors.  So, with all due
> respect, I don't think the folks who have put work into this will be
> all that interested in abandoning running code at this point.

My example was to highlight that without the rationale for why *this*
protocol was desiired any number of options would/could seem perfectly
reasonable and attractive.

>
>> Glossary:
>>
>> Global RPKI:
>> I disagree with this definition for two reasons. 1) I'm not aware of a
>> unified definition for 'distributed system' so this is all rather vague.
>
> The term has been used to describe DNS for decades.  Also see:
>
>   http://en.wikipedia.org/wiki/Distributed_computing

Citing wikipedia - the end is nigh!

>
>> Perhaps you could say 'published at a disparate set of systems'.
>
> I don't find that any clearer.  Readers who can't understand the words
> "distributed set" aren't likely to understand "disparate set" either.
>

I guess we remain in disagreement :).

>> 2) Limiting
>> the servers to be "at" the "IANA, RIRs, NIRs, and ISPs" is also premature.
>> It's not clear to me that these entities will run their own repositories,
>> nor are they going to be the only repository operators in the lifecycle of
>> the RPKI.
>
> This is essentially the same list as appears in section 1.1 of
> draft-ietf-sidr-arch, with the term "LIR" replaced by "ISP".
>
> I suppose we could add "or other service providers".

I think that would satisfy me.

>
>> Cache:
>> The words surrounding the fetch/refresh mechanisms of the RPKI is limiting.
>> Both draft-ietf-sidr-repos-struct and draft-ietf-sidr-res-certs allow for
>> other (future) retrieval mechanisms as defined by the repository operator
>> beyond RSYNC (loosely documented in RFC5781).
>
> Terry, you've made it quite clear that you disagree with the SIDR WG's
> decision to make rsync the mandatory-to-implement RPKI retrieval
> protocol, but you lost that argument a long time ago, and I fail to
> see the point of bringing it up here yet again.

That wasn't the intent Rob, please re-read the paragraph for the reality
that I think this document still needs to be flexible SHOULD a future
retrieval mechanism develop. If you still think that it shouldn't be
flexible - then we remain in disagreement.

>
>> Last sentence. "Trusting this cache further is a matter between the provider
>> of the cache and a relying party". In my mind the Relying Party was the one
>> that did the RPKI validation - would this not be better stated as "Trusting
>> this cache further is a matter between the provider of the cache and the
>> router operator".
>
> If a router is making decisions based on data given to it by a server,
> the router is the relying party in that relationship.  That the server
> in question was itself the relying party in another relationship does
> not change this.
>
> The picture here is not all that different from the way that some
> vendors have chosen to implement DNSSEC.  It's a two-tier security
> relationship: an end-to-end relationship between the publisher of
> signed objects and the validator of those signed objects, then a
> separate security relationship between the entity that validated the
> signed objects and the end entity that actually uses the data.

I think then we remain in disagreement on the phrasing, spelling out
precisely that the relying party identified here has a trust relationship
only with the cache, and not the larger RPKI is important.

>
>> Deployment Structure:
>>
>> Why repeat the definition of "Global RPKI"? It's superfluous.
>
> Because it's not a definition?
>
> I agree that the text here is similar to the definition, but this
> section is trying to describe the roles in the system.

Then I think the text needs work.

>
>> Local Cache: Again. 'Relying party' seems to be borrowed from the
>> CA/identity world. Unless you redefine that term here it seems as if the
>> "router" is making RPKI validation decisions. Which it is not. The router is
>> acting more like a NAS (See Radius, 2865) when talking to a local cache.
>>
>> The definition of "routers" seems to get this right - eg "a client of the
>> cache".
>
> See above.  "Relying party" is a security relationship term, not just
> a PKI term.
>
>> Operational Overview
>>
>> when you first use "ROA", please expand the TLA, and provide a reference.
>
> Done.
>

Thanks.

>> Serial Query
>>
>> I don't remember seeing a recommendation for how often a client (router)
>> sends a serial query. Is there a Min/Max? Surely doing it every second would
>> be excessive..
>
> Maximum is covered in section 6.2: the router must send a Serial or
> Reset Query no less frequently than once per hour.
>
> Minimum is a good question.  We had been assuming that, as this is an
> in-POP relationship with cache and router operated by the same party,
> there would likely be a knob in the router (router guys live for
> knobs) and setting it would be a matter of local policy.  If you want
> your router to beat up your cache server every minute, who am I to
> stop you?
>
> We needed to set a maximum because that affects the architecture of
> the cache (how long does it need to hold onto old data -- given the
> potential size of the data sets involved, one might implement the
> cache very differently if one needed to hold old data for a week
> rather than an hour).

Thus some recommendation text would be helpful.

>
>> IPv4 Prefix:
>>
>> "and nothing prohibits the existence of two identical
>>    route: or route6: objects in the IRR."
>>
>> Why even mention the IRR here? It just doesn't seem at all relevant. (and
>> isn't defined)
>
> Good catch.  Done.

Thanks

>
>> " IPvX PDUs" expand to IPv4 or IPv6. Globing into one is a misdirection
>> under a heading of 'IPv4 Prefix'
>>
>> IPv6 Prefix
>>
>> Some text here to say that the IPv6 data structure follows the same
>> semantics as the IPv4 data structure would be good.. or alternatively
>> restructure the document to Semantics, then describe the IPv4 and IPv6 data
>> structures as subheadings to Prefix PDUs.
>
> Done.

Thanks

>
>> Error Report
>>
>> What is "excessive length" of a PDU? at what point do you say "o.k, now I
>> can truncate".
>
> Too long to be any valid PDU other than an Error Report.  Done.

Thanks

>
>> Fields of a PDU
>>
>> For all types, instead of using "ordinal" can you use the exact description
>> of the number? eg unsigned integer? For me I always relate ordinals to set
>> theory.
>
> Done.

Thanks

>
>> PDU type, the e,g is incomplete shouldn't it be "IPv4 Prefix = 4" with a
>> forward reference to the IANA Considerations section?
>
> I think this is a matter of stylistic preference.

Yep. I can let that be.

>
>> Serial Number. "for example via rcynic", Is not defined and implementation
>> specific!
>
> Please read the words "for example".
>
> I suppose we could add a reference, but the last time we did that
> somebody objected to having a reference pointing to the source code
> for a particular implementation.

Do you need the example? Perhaps just remove it. (I may have missed it, but
I don't recall seeing bind, or any other reference code base mentioned in
any of the DNS documents.)

>
>> and there is a typo "completing an rigorously validated"..while
>> there, consider why you use the term 'rigorously'..
>
> Sigh.  Next time, please be explicit about the typo you're seeing, our
> eyes repeatedly bounced off the "an" here until after we'd posting
> version -25.  It's not worth yet another rev just to fix that.

ok. Sorry I wasn't explicit at the time.

>
>> are there situations when a validation is less rigorous? If so
>> explain.
>
> I suspect that my co-author was trying to say that one can't just
> retrieve the data, pull the ASNs and prefixes out of the ROAs, and
> feed them into the router, one has to do the RPKI validation first.
>
> I guess we can remove the word if it offends you, but it seems
> harmless.

I just want it to be clear that there is only one level of validation as per
the various RPKI object validation rules.

>
>> Session ID
>>
>> What is the risk of a cache server starting/restarting with the same session
>> ID and serial number as before, but with different cache contents? Is this
>> an entropy concern? Just thinking of a potential scenario where a router is
>> cache-wedged. Is this at all probable? and why not - some words here to
>> cover this would be good.
>
> We added several paragraphs on exactly this topic sometime around IETF
> Last Call, I suspect the version you reviewed did not have that text.
> I think we've addressed this point, please check the current text and
> let us know if there's a further issue here.

I will read.

>
>> Flags
>>
>> Can you reword the binary choice here? Do you actually need to delve into
>> 'right to announce'? This is really about RIB entry behaviors yeah?
>
> The semantics here are closely related to ROAs, which, as you no doubt
> recall, are Route Origin Authorizations, so the text here follows that
> model.
>
> With all due respect, I do not think that a discussion of RIB entry
> behavior here would be simpler.
>

fine.

>> Expand "IPvX".
>
> Done.
>

Thanks

>> Start or Restart:
>>
>> I think the terms in when a router needs to send a serial query or a reset
>> query need to be tighter. Saying MAY here is too loose. I would much prefer
>> to see a structure where if the router does not have a recorded serial for a
>> cache from a previous session, the router MUST send a reset query. Logically
>> you assume that to be the case, so be specific.
>
> I think this is a stylistic matter again.  The router MAY do two
> things here, one of which is only applicable if it has data from a
> previous broken session.
>
> The only real difference I see here between the current formulation
> and the MUST formulation you prefer is that, as currently written, the
> router could chose not to send anything at all initially; this option
> doesn't seem particularly useful, so I don't mind removing it, but
> neither do I see the difference between the current text and your
> suggested change as a big deal.

Perhaps choose whichever has the lower chance of confusion for the router.

>
>> Thereafter the router MAY send a reset query, and SHOULD send a serial
>> query. I suspect this is what the vendors (who have chimed in on the list)
>> have coded.
>>
>> This then corroborates section 4 where you suggest the router only send
>> serial queries for efficiency.
>
> Section 6.2 already says that the typical exchange is for the cache to
> send a Serial Notify, in the expectation that the router will schedule
> an immediate Serial Query.  We didn't make it any stronger than that
> because the folks implementing the router side of this expressed
> concern at the notion that the cache could tell them to do something
> (read: they understand that the notification mechanism will help speed
> convergence, but they're worried that the dinky CPUs they're stuck
> with in some of the relevant hardware will be swamped if they try too
> hard, which is why routers are allowed to ignore notifications and
> caches are rate-limited in sending them).

ok.

>
>> Transport:
>>
>> MiTM is Man in the middle as I and many others know it. 'Monkey/piggy/pickle
>> in the middle' is a child's ball game.
>
> Monkey-in-the-middle is a common non-sexist variant of this term.
> Welcome to the 21st century.

Going back to a gender-neutral section of a professional writing text from
my MBA, it highlights that arbitrarily changing the linguistic definition of
certain gender inclusive scenarios is poor form. If the language where
'Men-in-The-Middle" or "A-Man-in-The-Middle", then certainly change it.

Otherwise Man-in-the-middle is perfectly gender ambiguous. - But that may
also be my style and I will let the RFC Editor handle as appropriate.

>
>> " Therefore, as of this document, there is no mandatory to
>>    implement transport which provides authentication and integrity
>>    protection."
>>
>> if this is the case.. then why? what is the gain?
>
> OK, this is the elephant in the living room.
>

[..]

>
> Nobody is happy with this, but it's the least bad compromise we could
> find between what the IETF would prefer and reality in the field.
>

O.K.

>> why not then make the router fetch the signed objects and do the
>> validation internal - this again seems to be the 'missing
>> requirements' problem.
>
> See "currently shipping routing hardware", above.
>
>> SSH Transport
>>
>> State up front that you MUST use SSHv2. (instead hinting in the third
>> paragraph)
>
> Done.
>

Thanks.

>> TLS Transport
>> "Man in The Middle (MiTM)" please.
>
> Above.
>
>> Router Cache setup
>>
>> "When a more preferred cache becomes available, if resources allow, it
>>    would be prudent for the client to start fetching from that cache."
>>
>> How does the client (I assume router) know when to do this as cache's are
>> not synchronized?? How does a router tell if any particular cache has more
>> current data over another cache? what if two caches contradict each other?
>
> The document repeatedly states that the router has an ordered
> preference list of the caches it uses.  The text you quote here
> doesn't say "has more current data", it says "becomes available", ie,
> it stops rejecting connection attempts, signalling errors, or
> otherwise failing to be useful.

o.k.

>
>> Error codes
>>
>> 6: Withdrawal of Unknown Record (fatal), why drop the session? (which
>> presumably causes a restart) to a cache, assuming the cache is corrupt,
>> which will then send another Unknown Record, which is fatal... (repeat)??
>>
>> Why not mark the cache as corrupt at the client?
>
> This is one of several loss-of-synchronization problems.  The
> assumption is that the router may have (somehow) lost synchronization
> with the cache.  We don't really know which party is confused at this
> point, all we know is that the session itself is no longer useful
> because the router and cache are not communicating clearly.  So the
> router's data isn't necessarily corrupt.
>
> The router won't necessarily restart with this cache right away
> either, it has several options: it might try another cache, it switch
> to another set of data it has already loaded, or might try a reset
> query to this cache.

o.k.

>
>> Security Considerations:
>>
>> Transport Security. There are multiple valid options for a root trust anchor
>> including the structure from the IAB aligning it to the IANA. Perhaps
>> instead of saying " the IANA root trust anchor" say "Global RPKI root trust
>> anchor". Otherwise you might accidently find your validated cache only
>> covers unallocated and reserved blocks.
>
> I think you're saying that using the term IANA here is politically
> incorrect.

No. I'm saying that while discussions are underway, precisely which trust
anchor covers what is still on the table. At this stage one option has
IANA's RPKI CA being authoritative for only unallocated and reserved INRs.
It may be that there is a unified trust anchor above that, known loosely as
the global trust anchor. However tying the document to one particular TA
might result in a gross inaccuracy. Ultimately then, if the global trust
anchor is the IANA TA, you haven't lost.

Cheers
Terry