|
Re: [sidr] TSVDIR review of draft-ietf-karp-design-guide
2011-06-30 09:17:04
How much of this would change if the abstract began with:
This document captures the design guidance that the KARP working group
is using at the time of publication for guiding the chartered security
analysis and proposal work that it is doing.
And we put that in the front of the intro as well.
(The abstract needs to be replaced with an actual abstract. I had
thought that could be resolved in parallel with the IETF last call.)
Would that help, or would you have the same concerns?
Yours,
Joel
On 6/30/2011 9:52 AM, Joe Touch wrote:
Hi Joel,
On 6/30/2011 6:13 AM, Joel M. Halpern wrote:
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.
From the design guide section 1:
Readers must refer to the [I-D.ietf-karp-threats-reqs] for a
clear definition of the scope, goals, non goals and the
audience for the design work being undertaken in KARP WG.
I did so, and found issues there that caused problems here, which is why
those issues are included.
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.
There are more than a few who frequently refer to a protocol's "packets
on the wire". This is ambiguous and can mean:
- app messages (here, routing PDUs)
- transport messages (e.g., TCP segments)
- network messages (e.g., IP packets)
- link messages (e.g., ethernet segments)
- the physical media (e.g., WIFI)
Protecting each of these results in different kinds of defense. The
document needs to avoid the use of this term as if it were well-defined
in the IETF literature and unambiguous within the IETF community.
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.
Neither document should expect that readers are familiar with the
charter; relevant context should be summarized in the intro (and is not,
currently).
The KARP charter says:
---
The KARP working group is tasked to work with the routing protocol
working groups in order to improve the communication security of the
packets on the wire used by the routing protocols. This working group is
concerned with message authentication, packet integrity, and denial of
service (DoS) protection. At present, this charter explicitly excludes
confidentiality and non-repudiation concerns.
...
Routing protocols use a range of transport mechanisms and communication
relationships. There are also differences in details among the various
protocols. The working group will attempt to describe the security
relevant characteristics of routings protocols, such as the use or
non-use of TCP, or the frequent use of group communication versus purely
pairwise communication. Using these characteristics, the working group
will then provide suitable common frameworks that can be applied, and
tailored, to improve the communication security of the routing
protocols. In later phases, it is expected that the working group will
investigate the suitably of defining conceptual structures and APIs, so
as to enable further work to be more effective.
---
Again, I note that "on the wire" is not clear, nor the term "packet".
The term "transport mechanisms" is overloaded, but in the IETF tends to
refer to layer 4; that's not appropriate here, as some important routing
protocols are directly layered over L2 or L3.
Discussion of layers where it is not needed is a distraction.
A design guide to secure routing protocol message exchanges needs to
clearly identify, by example, the expected kinds of protection needed
for the message exchange. This breaks down to two parts:
A- securing the message content
B- securing any information provided by the way in
which the messages are exchanged
1- securing explicit info (e.g., IDs,
if relied upon by the routing protocol)
2- securing implicit info (e.g., connection
status, message ordering or success, etc.,
as used by the routing protocol)
AFAICT, KARP is focused on (B) which is necessarily in the context of
L2, L3, and/or L4 {where SIDR addresses (A)}. That's fine, but a
*design* guide should be more clear about what B means, and what kinds
of things to look out for or address.
If there are specific places where such additions would be helpful, that
is a comment we can react to.
I refer you again to the intro, which states:
... Section 8.2 calls for "[t]ightening the
security of the core routing infrastructure." Four main steps
were identified for that tightening:
o More secure mechanisms and practices for operating routers.
This work is being addressed in the OPSEC Working Group.
o Cleaning up the Internet Routing Registry repository [IRR],
and securing both the database and the access, so that it
can be used for routing verifications. This work should be
addressed through liaisons with those running the IRR's
globally.
o Specifications for cryptographic validation of routing
message content. This work will likely be addressed in the
SIDR Working Group.
o Securing the routing protocols' packets on the wire
This document addresses the last bullet, securing the packets
on the wire of the routing protocol exchanges.
The third bullet describes securing routing protocol messages as out of
scope. The last sentence describes "on the wire" as in scope, again as
if this were a clear indication of what needs to be protected.
As a lesser issue, it is not clear that the different ways of delivering
multiple content are actually relevant to the design guidleines
document.
Can you please then explain what "on the wire" means if not "differnt
ways of delivering multiple content"? Isn't that exactly the scope?
> 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.
The difference between unicast and multicast is important, but so is the
difference between whether a protocol relies on a connection being up,
or message delivery being ordered. Again, specifically:
B- securing any information provided by the way in
which the messages are exchanged
1- securing explicit info (e.g., IDs,
if relied upon by the routing protocol)
2- securing implicit info (e.g., connection
status, message ordering or success, etc.,
as used by the routing protocol)
IMO, neither B1 nor B2 is sufficiently addressed in this doc, and
neither can be addressed in the absence of a clear discussion of the
different properties of L2, L3, and/or L4 as they impact routing
protocols over which they operate.
Joe
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(_at_)ietf(_dot_)org 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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/sidr
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
|
|