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

[SM <[e-mail]>]

Hi John,
At 04:48 22-12-2011, John Leslie wrote:
>    Surprisingly, a Google search on "ISBN 9780876094815" actually turns
>up something arguably appropriate:

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

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

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