Considerations for Internet Routing Registries (IRRs) and Routing Policy Configuration
draft-ietf-grow-irr-routing-policy-considerations-06

I support Adrian's Discuss on the need to have Terry's review comments addressed.

I also found this draft a bit hard to read and parse - though not to the extent of pulling
out specific examples, but please do think about Barry's comments as well.

Although the abstract and intro claim that the draft will provide a discussion of the
existing or remaining concerns, I would STRONGLY (not quite DISCUSS but...) like 
them to be pulled out more clearly.  Without this, the draft seems to be more retrospective 
and rambling than clearly articulating what was a problem, what changed, and what still 
remained as a problem.

For instance, from reading the draft, I would say that:
   a) Getting fresh IRR data is still a problem.  Pull mechanisms use long intervals based
       upon historic problems (see Sec. ...) and push mechanisms are not fully described.
   b) RPKI provides a solution only for verifying route origination but this is not sufficient
      for verifying IRR data because such data also includes asnum, etc.
   c) Stale data in IRRs:  incentives don't exist for removing stale data and overriding the
       existing data requires work and has the risk of black-holing if the data wasn't really stale
   d) Propogation delay across different ISPs affect how rapidly changes can occur.
   e) Configuration based on the new IRR data is less operator-intensive because of the ability
       to use NetConf to deliver the updates, but a lack of vendor-agnostic models still makes
       such updates complicated.
   f) Router capabilities are rarely a problem anymore.  (Incremental updates of prefix-lists, 
      more static memory, BGP extensions to push new config in without traffic-impacting side-effects).

I'm sure I've missed some and maybe gotten a few wrong- but I'd really like to see some actual 
takeaways.  This currently leaves me feeling like I had a good dinner conversation chatting about 
how bad the old times were but without any action items or guidance for the future to improve.

I agree with many of the other ADs' comments on this document.

[My comments are similar to Alia’s review of –05.]

It is somewhat hard to pinpoint the expected outputs promised in the Introduction, where is says that the "purpose of this document is to catalog past issues...  Additionally, it provides a discussion regarding which of these issues still pose problems in practice, and which are no longer obstacles…”  Section 3 seems to provide a roadmap of the document pointing out the pieces covered:  "First, accuracy and integrity of data contained within the IRR.  Second, the Resource Policy Specification Language (RPSL) used to represent various types of data in the IRR.  Third, operation of the IRR infrastructure, i.e.: synchronization of resources from one IRR to other IRRs.  Finally, the methods related to extraction of policy from the IRR and the input plus activation of that policy within routers.”    While that is ok, there’s no clear correlation with the TOC.

The contents of the document don’t have to strictly be reflected in the TOC, but it would be nice to at least call out which sections cover the points listed above.  According to my reading, that would be 4 (for #1), 5.1 (for #3) and 5.2, 6 and 7 (for #4).  It is not clear to me that independent issues related to RPSL (and not related to #1) are covered..any are intermingled in Section 4.

Going back to the purpose of the document.  Section 8 (Summary) says that "many of the problems that have traditionally stifled IRR deployment have, themselves, become historical”.  But in my reading the only issue that seems to not be an obstacle anymore is the graceful application of policy in BGP (Section 6 and 7).  If the intent was to highlight others as non-issues then that should be made clearer.


Nits:
Section 4. (Accuracy and Integrity of Data Contained within the IRR) s/section/sections
Section 5.1. (Replication of Resources Among IRRs)  s/has a several weaknesses/has several weaknesses
Section 5.2. (Updating Routing Policies from Updated IRR Resources)  s/An ISP's customers/An ISP's customer

I find some of the writing throughout the document to be a bit hard to get through -- not to the extent that I think it's a serious problem, but enough so that I'd say this is making the reader work a bit too hard.  Some examples:

   While these resources
   are generally allocated by hierarchical authorities, a general
   mechanism for formally verifying (such as through cryptographic
   mechanisms) when parties have been allocated resource remains an open
   challenge.  We generally define such a system a Resource
   Certification System, and we note that some candidate examples of how
   such a general system might be implemented and deployed exist[.]

The structure of both of these sentences makes understanding them require a bit of rewinding and re-parsing, at least for me.  Phrases such as "have been allocated resource" seem odd ("allocated resources" or "allocated a resource" would seem better).  Phrases such as "some examples exist" are straightforward, but get harder when a long modifying phrase is stuck in before "exist", as here.  This is an example; there are other such bits in the document.

In the end, it's probably fine, though I think it'd be a good idea to alert the RFC Editor to watch for complicated sentences whose structure makes then a bit difficult to read smoothly.  Below I suggest a few specific sentences that I hope the authors will re-do themselves, before it goes to the RFC Editor.

-- Section 4.1 --

   One of the largest weaknesses often cited with the IRR system is that
   the data contained within the IRRs is out of date or lacks integrity.
   This is largely attributable to the fact that existing IRR mechanisms
   do not provide ways for a relying party to (cryptographically) verify
   the validity of an IRR object.  That is, there has never existed a
   resource certification infrastructure that enables a resource holder
   to authorize a particular autonomous system to originate network
   layer reachability advertisements for a given IPv4 or IPv6 prefix.

Two questions here:

1. The last sentence is written as a clarification of the one before it ("that is..."), but seems to veer.  Would it perhaps be better to say, "...that enables a resource holder to verifiably authorize...", or, "...that enables a resource holder to provide verifiable authorization that a particular autonomous system may originate..." ?

2. This clearly explains the "lacks integrity" piece, but adding cryptographic verifiability will not fix out-of-date information, will it?  Isn't there also an issue of keeping the information current in the first place, which is not mentioned here?

-- Section 4.5 --

   Only now is an
   experimental test bed that reports to provide this function

I think "purports" is the word you're looking for here.

-- Section 5.2 --

   An ISP's customers may not adequately plan for pre-planned
   maintenance or, more likely, need to rapidly begin announcing a new
   IP prefix as a result of, for example, an emergency turn-up of the
   ISP customer's new downstream customer.

I'm having trouble making sense of this sentence.  The subject seems to change throughout the sentence, starting as "an ISP's customers", and shifting to the ISP later.  Can you please re-word this, perhaps splitting it into two sentences?  (It'd also be nice if you'd use "might" to refer to something that might happen, and save "may" for referring to something that's *allowed* to happen.)

   It is likely that the length of time at which IRRs mirror
   changes will have to be dramatically reduced with a corresponding
   reduction in time at the ISPs that, in turn, need to evaluate whether
   changes in a set of IRR resources need to get reflected in updated
   router policies that will get pushed out to ASBR's, connected to
   peering circuits, on their network.

I get this one, in the end, but it's also in need of splitting into two, please.

-- Section 6 --

   Ultimately, either of the two scenarios above further lengthen the
   effective time it would take for changes in IRR resources to take
   affect within BGP in the network.

That should be "take effect", not "take affect".  And I think the combination of "effective time" and "take effect" can be confusing, so maybe try some rewording?

I see you have some high-level considerations that could encompass the various security properties that would be expected, but would prefer to see them spelled out a bit.  For instance, in the first paragraph of the security considerations section:
"operators may want to be
   circumspect about ingesting contents from external parties"

Wouldn't you want to see integrity protection so that the operators would have some level of assurance that the source is who they think it is and that the data has not been tampered.  This might apply to the described examples where FTP is used to share information.  Authentication would be helpful here too.

Then, if automation increases, you would also want confidentiality (session encryption for privacy and security reasons).  C

This this is a summary of current state, this is just a comment.  But I would think these properties are used in the current state - at least integrity protection and authentication.  (Security's CIA principle)

Thanks.

Thanks for this. I learned from reading it and following
some links etc. I think other readers will be similarly
educated.

- I agree with Adrian's request that the routing review
be discussed. In particular, wrt the relationship
between this work and the RPKI - it'd be good that that
be (checked as having been) documented correctly. No
disrespect to the authors here, but the RPKI vs. IRR
stuff here is not that crisply described - most likely
(I'm guessing) because that relationship is just in
reality vague. But if I'm recalling correctly some of
the very capable authors here aren't the biggest fans of
the RPKI so it'd be good for them and this document that
their description of RPKI be challenged now a little bit
rather than that be done later (if that has not already
happened, which may well be the case).

- 5.1, I'd be interested in why RFC2725 is now seen as
then having been a barrier to deployment and whether or
not that is still considered to be the case. Put another
way - was the problem the security requirements or the
design provided in 2725? (Note, I'm not asking for any
change, just wondering.)

- section 6 has a "[REF?]" that's presumably an undone
TBD

Thank you for putting the effort into this draft!

The latest revision is improved, and addresses 98% of my comments when I was wearing a routing area directorate reviewer hat. Mostly I'm pleased to see a sentence in there which highlights that the RPKI doesn't carry routing policy information. I think there is a very real undertone in this document that shouldn't be avoided in that the RPKI takes steps to routing security, but misses a mark on policy integrity.

I still don't buy the ideal that 10gig circuits are perceived as the norm - but happy to let that go as a future ideal.. mores law and all :)

This document is one of the better outcomes of documenting in the IETF what was (is) and why wrt routing.