Subject: [karp] Responses to Comments for draft-ietf-karp-threats-reqs-01

From: Russ White <[email-masked]>
Date: Fri, 07 Jan 2011 15:38:26 -0500

Y'all:

In the mess of trying to get through the comments to this document, we
split things up and somehow lost track of what has been responded to and
what hasn't. I'm hoping Manral will post a new version for review, but I
know there were two specific comments we didn't address, and I wanted to
provide some information here in case others wanted to discuss these two.

==
In the section on brute force attacks, the document says:

> While it is impossible to make brute force attacks on keys completely
> unsuccessful, proper design can make such attacks much harder to
> succeed.

The comment was:

> I don't agree that this is true in any practical sense. If your keys
> are 256 bits long, then brute force attacks are effectively impossible.

It seems to me that brute force attacks are always a matter of
horsepower and algorithms. As the horsepower available in silicon
increases, the possibility of a brute force attack increases with it.
Clouds of computers (such as SETI) can bring a lot of horsepower online
very quickly --so I don't think we should ever rule out caution in the
space of key length, or using longer keys where possible.
==

==
The draft says:

> The authentication mechanism in the Routing Protocol MUST be
> decoupled from the key management system used.  It MUST be
> obvious how the keying material was obtained, and the process
> for obtaining the keying material MUST exist outside of the
> Routing Protocol.  This will allow for the various key
> generation methods, like manual keys and KMPs, to be used with
> the same Routing Protocol mechanism.

The comment was:

> I don't agree with this requirement, which precludes much of our effective security technology, such as, for instance, TLS.

This is probably one of the most controversial areas on which we need to
agree as a WG. My sense is that tying keying materials to the control
plane protocols is a bad thing --something like a layering violation, in
a sense. If we look at why layering is "good network hygiene," we find
the reason is to split complexity from complexity and divide failure
domains. Protocols that provide reachability information, either at
layer 2 or layer 3, seem very complex to me (and this is probably where
the disagreement lies --many people think these protocols are relatively
easy to digest and manage, so they don't see the complexity I do), and
the protocols and "stuff" that goes around key management appears to be
very complex to me, as well.

So my sense is that dividing the reachability control plane from the
encryption control plane is a "good thing," likely to result in fewer
poorly understood feedback loops, and fewer unintended consequences. I'm
pretty strongly in favor of splitting these where possible, and making
the API between as transparent as possible.

But I'm willing to hear arguments to the contrary.
==

:-)

Russ

-- 
[email-masked] :: CCIE :: CCDE :: <>< Grace Alone

Now, we never can annihilate a penalty. We can only divert it from the
head of the man who has incurred it to the heads of others who have not
incurred it. A vast amount of "social reform" consists in just this
operation. -William Graham Sumner

---

From: Sam Hartman <[email-masked]>
Date: Mon, 10 Jan 2011 14:33:12 -0500

>>>>> "Russ" == Russ White <[email-masked]> writes:

    Russ> So my sense is that dividing the reachability control plane
    Russ> from the encryption control plane is a "good thing," likely to
    Russ> result in fewer poorly understood feedback loops, and fewer
    Russ> unintended consequences. I'm pretty strongly in favor of
    Russ> splitting these where possible, and making the API between as
    Russ> transparent as possible.

    Russ> But I'm willing to hear arguments to the contrary.  ==

Russ, I think there is consensus on the requirement currently in the
document.  I don't think the compelling arguments are about what the
right thing to do is:m y personal opinion is that the requirement is not
the best technical approach, but that this split is not nearly as bad of
a thing as I at first thought it was when I started thinking about KARP.

However people have made claims that those doing the implementation work
in this space strongly prefer the split and that adopting a requirement
for this split will make it more likely to succeed.  I don't think that
such a split is bad enough on a technical front that we should rule it
out. So, if the split gets us implementations and the lack of a split
gets us irrelevance, let's go with the requirement.

So, my question to the WG as a whole is do we actually want to have
another round of discussion on whether Russ's technical argument above
is correct? Or are we willing to accept this requirement as a practical
necessity? My personal opinion is that this requirement is not a
technical issue and so having this as a technical discussion is not an
effective strategy. I feel strongly that we should make forward progress
and do not feel that strongly about whether this requirement should be
present.

That said, if people want to have the technical discussion I'm happy to
join it on the list or in private.