I am conufsed by this review of the KARP design guidelines document.
My first reaction was that I had trouble understanding the general
points. However, when I looked at the more detailed explaantion, what I
see is "The threats document should ...". But this is not a review of
the threats document.
As a result, when the review then says "the document" I have no idea
what document is meant.
In addition to that general comment, I am completely unable to
understand the reviewers concern with the use of the term "on the wire".
I can believe that there is an issue with the way it is used, but have
no clue how to begin to address it.
Similarly, there is an assertion that it is important for the document
to be more clear on what layers are in and out of scope. This is
comment seems to be an assertion by the reviewer not grounded in the
document. Neither document is not a scope document. The scope is
defined by the charter. Discussion of layers where it is not needed is
a distraction. If there are specific places where such additions would
be helpful, that is a comment we can react to.
As a lesser issue, it is not clear that the different ways of delivering
multiple content are actually relevant to the design guidleines
document. The different routing protocols have their modes of
operations. Ones which send distinct messages to distinct peers are
different from ones which, as routing protocols sned single messages to
broadcast or multicast. As such, it is not at all clear what the
reviewer is asking be clarified in this regard.
Yours,
Joel M. Halpern
On 6/30/2011 1:54 AM, Joe Touch wrote:
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...".
-----
_______________________________________________
sidr mailing list
sidr@xxxxxxxx
https://www.ietf.org/mailman/listinfo/sidr
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf