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

["t.petch" <[e-mail]>]

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

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

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

> 
>    "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 
> 
> _______________________________________________
> Ietf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ietf
> 
>