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
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf