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

From: Hannes Gredler <[email-masked]>
Date: Wed, 21 Dec 2011 08:27:44 +0100

hi,

hereby i want to declare (by myself and on behalf of Juniper Networks Inc.),
support for the the rpki-rtr protocol. Juniper Networks Inc. has got an implementation
of the protocol based on, draft-ietf-sidr-rpki-rtr-19. Our implementation
passed interop testing with 3 different rpki caches (BBN, RIPE, ISC) and got
a exposure to a couple of our tier-1 SP customers for labe test purposes.

thanks !

/hannes

---

From: Keyur Patel <[email-masked]>
Date: Wed, 21 Dec 2011 14:22:46 -0800

Folks,

I like to voice my support (on behalf of Cisco Systems) as well. Cisco
Systems has recently shipped RPKI Router protocol implementation (in IOS
software release). 

Our implementation has been tested with two different RPKI cache
implementations (RIPE, RPKI.NET) and is currently going through lab tests
with our customers.

We are also in process of writing an implementation survey for this
protocol.

Regards,
Keyur

On 12/20/11 11:27 PM, "Hannes Gredler" <[email-masked]> wrote:

> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 22 Dec 2011 00:59:51 +0100

Hi,

I think this is great news that two vendors are shipping a pre-standard 
implementations and are willing to produce implementation survey on it.

However I do support both Danny's and Shane's concerns.

In addition I have already voiced my own concern that current scenario 
only discusses one particular deployment model where all edge ASBRs 
perform validation and that the validation data comes from local caches.

IMHO this is way too limited model for any practical deployment of BGP 
Origin Validation.

Best regards,
R.

> On 12/20/11 11:27 PM, "Hannes Gredler"<[email-masked]>  wrote:
>
>> hi,
>>

---

From: Terry Manderson <[email-masked]>
Date: Wed, 21 Dec 2011 17:43:23 -0800

Hi,

Apologies for my lack of attention to date on this topic, so speaking only
for myself here.

At this stage I do not support this document's publication.

Starting with the document structure, I see no reference to a set of
requirements. The introduction is rather vague, and if anywhere that is
where I would expect to see such a requirements description. This means for
the rest of document I found myself asking "why" on many levels.

When I got to the end of the document I felt that the protocol borders on a
wheel re-invention exercise. When you think about a router simply being a
client to a cache that is providing RIB access tokens for a route using a
mechanism that is a secure, stable, scalable, known (by both vendors and
operators), and is extensible, I'm more likely to swing to RADIUS in doing
such a service with nicely structured AV-Pairs and sane timers for
reauth/retry etc. Even the SME's know radius for their WPA enterprise kit.

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.
Perhaps you could say 'published at a disparate set of systems'. 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.

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).

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".

Deployment Structure:

Why repeat the definition of "Global RPKI"? It's superfluous.

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".

Operational Overview

when you first use "ROA", please expand the TLA, and provide a reference.

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..

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)

" 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.

Error Report

What is "excessive length" of a PDU? at what point do you say "o.k, now I
can truncate".

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.

PDU type, the e,g is incomplete shouldn't it be "IPv4 Prefix = 4" with a
forward reference to the IANA Considerations section?

Serial Number. "for example via rcynic", Is not defined and implementation
specific! and there is a typo "completing an rigorously validated"..while
there, consider why you use the term 'rigorously'.. are there situations
when a validation is less rigorous? If so explain.

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.

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?

Expand "IPvX".

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.

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.

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.

" 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? why not then make the
router fetch the signed objects and do the validation internal - this again
seems to be the 'missing requirements' problem. And in such events - there
are a million solutions.

SSH Transport

State up front that you MUST use SSHv2. (instead hinting in the third
paragraph)

TLS Transport
"Man in The Middle (MiTM)" please.

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?

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?

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.

Cheers
Terry

---

From: Lixia Zhang <[email-masked]>
Date: Wed, 21 Dec 2011 21:49:26 -0800

hmm...
since when did IETF last call start soliciting *company* support?
I had thought the rule says that we all participate as individuals.

confused, 
Lixia

---

From: SM <[email-masked]>
Date: Wed, 21 Dec 2011 23:35:07 -0800

Hi Lixia,
>I had thought the rule says that we all participate as individuals.

The rule is overruled by ISBN 9780876094815. :-)

Regards,
-sm

---

From: John Leslie <[email-masked]>
Date: Thu, 22 Dec 2011 07:48:02 -0500

> The rule is overruled by ISBN 9780876094815. :-)

   SM has a weird sense of humor. ;^)

   Surprisingly, a Google search on "ISBN 9780876094815" actually turns
up something arguably appropriate:

"Internet Governance in an Age of Cyber Insecurity"
by Robert K. Knake
published by Council on Foreign Relations

   It is available for free download from cfr.org (55 pages).

   Brief skimming shows it to be much what I would expect from CFR
(not worth my time to read carefully), and not attempting to change
actual IETF process, though perhaps I missed something...

--
John Leslie <[email-masked]>

---

From: Andrew Chi <[email-masked]>
Date: Thu, 22 Dec 2011 11:41:38 -0500

I'm currently working on a server implementation of the RPKI-RTR 
protocol to incorporate into a suite of RPKI relying party tools.  Based 
on this work, I believe the proposed specification will meet the needs 
of implementers.

I support the publication of draft-ietf-sidr-rpki-rtr as well.

-Andrew

---

From: SM <[email-masked]>
Date: Thu, 22 Dec 2011 13:10:11 -0800

Hi John,
>up something arguably appropriate:

Which obviously is not about an IETF last call soliciting *company* 
support. :-)

>actual IETF process, though perhaps I missed something...

Well, why bother changing a process when would be is easier to select 
the decision-makers.   Anyway, the current revision of the draft is 
draft-ietf-sidr-rpki-rtr-22.

In the Abstract Section:

   "In order to formally validate the origin ASs of BGP announcements,
    routers need a simple but reliable mechanism to receive RPKI
    [I-D.ietf-sidr-arch]"

It would be better to remove that reference.

draft-ietf-sidr-arch-13 could be a normative reference instead of an 
informative one if the protocol described in this draft is part of 
the infrastructure to support secure Internet Routing.

In Section 2:

   "Global RPKI:  The authoritative data of the RPKI are published in a
       distributed set of servers at the IANA, RIRs, NIRs, and ISPs, see
       [I-D.ietf-sidr-repos-struct]."

There isn't any mention of IANA, the RIRs or NIRs in 
draft-ietf-sidr-repos-struct-09 or draft-ietf-sidr-arch-13.

   "Session ID:  When a cache server is started, it generates a session
       identifier to uniquely identify the instance of the cache and to
       bind it to the sequence of Serial Numbers that cache instance will
       generate.  This allows the router to restart a failed session
       knowing that the Serial Number it is using is commensurate with
       that of the cache."

The change was probably in response to the following comment in the 
Secdir review:

   "The cache identifies its boot instance via a nonce, and the client
    routers are supposed to record the nonce and discard all records if
    the nonce changes.  The nonce is only 16 bits, though, and the
    probability of two boot instances choosing the same nonce is too high,
    in my opinion."

Section 3 mentions a deployment structure for RPKI and repeats some 
definitions from the Glossary Section.

In Section 5.9:

   "If error text is present, it SHOULD be a  string in US-ASCII,
    for maximum portability; if non-US-ASCII characters are
    absolutely required, the error text MUST use UTF-8 encoding."

A reference for the encoding could be added.

Is the Integrity protection for payloads also desirable to protect against
man-in-the-middle attacks (RFC 4949)?

Section 7 has a MUST implement for an unprotected transport.  Lower 
requirement levels are used for more protected protocols.  Section 9 
mentions that:

   "Small End Site:  The small multi-homed end site may wish to outsource
       the RPKI cache to one or more of their upstream ISPs."

The Secdir review mentions that:

   "The answer is a simple protocol that concentrates assuring record
    freshness and punts security to some preconfigured point-to-point
    communication with some kind of transport security."

 From Section 11:

   "As this document describes a security protocol, many aspects of
    security interest are described in the relevant sections."

Quoting a comment from an IETF participant:

   "The operator's server to the operator's routers only involves the
    operator's internal network.  While I would personally prefer a
    mandatory-to-implement mechanism, I can see that operators do not
    necessarily want prescriptive statements on this part of the
    specification."

The upstream ISP isn't part of the operator's internal network.

Regards,
-sm

---

From: "t.petch" <[email-masked]>
Date: Wed, 28 Dec 2011 11:52:10 +0100

----- Original Message ----- 
From: "SM" <[email-masked]>
To: "John Leslie" <[email-masked]>
Cc: "IETF-Discussion list" <[email-masked]>
Sent: Thursday, December 22, 2011 10:10 PM

> draft-ietf-sidr-repos-struct-09 or draft-ietf-sidr-arch-13.

Odd; when I look at draft-sidr-arch-13 s1.1, I see IANA, RIR,
NIR along with LIR etc.  Granted I do not see RIRs or NIRs but
I would allow the singular to stand for the plural.

Tom Petch