Hi, all,
I've reviewed this document as part of the transport area directorate's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the
document's authors for their information and to allow them to address
any issues raised. The authors should consider this review together with
any other last-call comments they receive. Please always CC
tsv-dir@xxxxxxxx if you reply to or forward this review.
The document discusses design issues for protecting routing protocols.
The most problematic issue is the term "on the wire" which is used in
various contexts to imply physical, link, network, or transport protocol
layers. This needs to be clarified.
Transport protection appears to be a potential focus of the design
guide, but is inconsistently discussed. In some cases, transport issues
are raised (TCP issues for BGP); in other cases, the relevant transport
isn't even noted (e.g., RIP over UDP). This should be corrected throughout.
It is important for this document to be more clear on what layers were
in scope for the design guide, and what guidelines are being given with
respect to those layers, even in a general sense.
Further information on these issues is provided below. There is
additional feedback provided below ("other notes") as a suggestion.
I hope this feedback will be useful to the authors, and will be glad to
provide further assistance either on- or off-list as useful.
Joe
---------------------------------------------------------------------
>> please note that some of these comments apply to the
draft-ietf-karp-threats-reqs-03 as well; further, there is duplicate
text that is not needed in both these docs. FWIW, the threats-reqs doc
has many issues as well which are not addressed here.
Of the four issues noted in the intro, the last uses the ambiguous term
"on the wire". This is confusing in both this and the threats doc, and
many times both docs us the term 'wire' or 'bits', all of which would
typically indicate either the link layer or the physical media or both.
There is no rationale for this focus in either document.
The threats document should more clearly indicate *why* protection
beyond the routing messages (the SIDR work) is needed, and what the
expected threats are. These appear to be:
- routing protocols often rely on information in the
link, transport or network packets
- routing protocols often rely on properties of transport
connections to infer reachability, e.g., if a TCP connection
cannot stay up, then the endpoint's routes should not be
considered reachable
(if there are other reasons, please clarify) The threats then appear to be:
- spoofing link/network addresses
- spoofing transport ports
- disrupting the TCP connection (where TCP is used)
Note that falsification (as noted in the threats doc) is not in this
list since it is (IMO) clearly the purvue of the SIDR work. Also out of
scope should have been any of the interference issues, unless the
*performance* of the TCP connection needs protection.
This doc then may need to protect the link or network protocol ID and/or
transport protocol from interference. This should be more clearly stated
in the threats doc, IMO, and the term "on the wire" should be avoided.
The discussion of multicast should note that multicast can be
implemented by broadcast, true multicast, or serial unicast; these may
have different security requirements.
The document should more clearly indicate the underlying protocol used
as a key property of a routing protocol, especially because (as above)
this document appears to focus on guidelines for link, network, and/or
transport protocols. E.g., the discussion on OSPF, RIP, and ISIS should
more clearly indicate that, e.g., RIP runs over UDP, OSPF runs over IP
directly, and IS-IS runs natively over L2. Similar info would be useful
for BFD, RSVP, etc.
The document is unclear on its overall advice, other than a somewhat
general description of "do good stuff". E.g., it notes:
Not all routing protocol authentication mechanisms provide
support for replay attacks, and the design teams should
identify such authentication mechanisms and work on them so
that this can get fixed. The design teams must look at the
protocols that they are working on and see if packets captured
from the previous/stale sessions can be replayed.
More specific advice would be, e.g.:
Not all routing protocol authentication mechanisms provide
protection from replay attacks. Such deficiencies should
be addressed at that layer, rather than having design
teams conclude that such systems thus require lower layer
(transport, network, or link) protection from replays.
----
Other notes:
Overall, this document would benefit from a revision focused on
clarification, where the focus of each section and advice were made more
clear.
The abstract is excessively detailed and doesn't get to the point until
"This document...". Everything preceding that should be removed, and the
result should be appended with a few sentences summarizing the
recommendations.
The intro refers in a lot of detail to the motivation for the doc (some
of which may be historically important but is not relevant to the doc
itself), but only briefly notes the KARP threats document. This
document's observations should be motivated by addressing those threats,
so it would be important to summarize them in this doc in the intro as
context.
The summary of RFC 4984 discusses four tightening steps as if they were
indicated by that RFC; that RFC only suggests tightening itself. This
doc should more clearly indicate that "The WG identified four...".
-----
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf