Re: next task, applicability statement

Stephen Kent wrote:
> At 1:25 PM -0700 6/1/05, Joe Touch wrote:
> 
>>-----BEGIN PGP SIGNED MESSAGE-----
>>Hash: SHA1
>>
>>Stephen Kent wrote:
>>...
>>
>>> I do not mean to suggest that the possible invalidation of one of the
>>> several proposed rationales for BTNS should cause BTNS to dissolve.
>>> But, I recall that this specific motivation was used to justify
>>> adopting IPsec as the basis for BTNS, vs. SSL/TLS, because of the
>>> need to protect BGP sessions against spurious TCP RESETs. If we
>>> decide that BGP session protection is not likely to be effected via
>>> IPsec, unless the DoS concerns are addresses to the satisfaction of
>>> ISPs, then we might revisit the decision that IPsec is the candidate
>>> protocol to be used for BTNS.
>>
>>Protecting BGP sessions (i.e., TCP connections) against control attacks
>>(e.g., RSTs, ACK spoofing, etc.) requires a TCP or IP security
>>mechanism. SSL is insufficient to protect the TCP connection.
>>
>>It is understantable that this presents a DOS attack, but so does any
>>algorithmic protection, even at the application layer.
> 
> not true. I initiated discussion of this issue on the RPSEC list a 
> while ago. We came to the conclusion that there is a reasonable way 
> to address this specific sort of concern in a way that differs from 
> what protocols like IPsec or SSL try to do.  Let me explain.
> 
> The goal in this context is to provide a rate limiting mechanism for 
> control traffic, to minimize the possibility of overwhelming 
> bandwidth or computation limited elements of a system. Because rate 
> limiting is the goal, all one needs is a tag for each packet, readily 
> checked by the receiver, that tells whether the packet is potentially 
> legitimate and thus worthy of further examination. The tags need to 
> be unpredictable by an adversary, but need not be bound to the 
> packet, cryptographically. If an attacker strips a tag from a 
> legitimate packet and attaches to a bogus packet, one would rely on a 
> higher level security protocol to detect and reject the integrity 
> violation. At worst, an attack of this sort results in one-for-one 
> replacement of good packets with bad packets, and that is consistent 
> with the rate limiting goal of the mechanism.

That is exactly what I meant when I described 'cookie mode'; IMO, it'd
be useful to allow IKE to negotiate and potentially renegotiate these
cookies, as well as to check them at the IPsec level.

> There are at least two other criteria one wants for the tags: they 
> should be very fast to generate, and the receiver checking mechanism 
> should be able to tolerate packet loss over reasonable windows. Thus 
> some sort of RNG, with an ability to step forward for a modest 
> length, quickly, is appropriate.  One also needs to be able to 
> distribute and change the secrets shared between each transmitter and 
> receiver, and to resync in the even of prolonged packet loss or loss 
> of state by either end. Protocols for these functions pose another 
> possible avenue of DoS attack, and so they need to be rate limited as 
> well, via a different mechanism, e.g., a receiver might refuse to 
> accept a purported resync packet from a specified source more than 
> once per minute.

There are varieties of cookies, agreed - some static (helps only with
off-path) and reused, some dynamic using RNGs, etc.

And agreed, IKE needs to be rate-limited as well.

> This analysis suggests that trying to use IPsec for BGP security, 
> absent an underlying rate-limiting mechanism of the sort indicated, 
> is probably not going to be acceptable. If the rate limiting 
> mechanism were in place, then one could implement IPsec in the 
> management processor, not on a lime card, and not worry about DoS 
> issues. In fact, if an ISP didn't believe that the path traversed by 
> management traffic were subject to MITM attacks (the threat model you 
> proposed for BTNS), then they might not even bother with IPsec for 
> BGP traffic, since the rate limiting scheme would reject bogus 
> traffic generated off-link more efficiently!

The threat model includes off-path and on-path, FWIW.

However, the above is again why I believe the generic capability for
lower-quality algorithms is needed, independent of where.

However, they do need to be in the IPsec or TCP/"MD5" level to protect
connections; SSL does not protect the TCP connection, and since BGP
interprets TCP disconnects as signal-path failures, SSL is insufficient
to protect a BGP peer.

>> A multilevel
>>solution, with different levels of effort, would be (as always) useful.
> 
> What I describe above is a multi-layered approach, but one with a 
> well understood division of security responsibility for each protocol.

The division of security responsibility already lies in the selection of
the algorithm - authentication vs. encryption, e.g., as well as strength
of the algorithm. There's no need for a new protocol as much as for new
algorithms.

>>Which is why, IMO, it'd be useful to have "cookie-mode" hashes,
>>header-only hashes, etc. - where a single packet might have multiple
>>levels of security applied:
>>
>>	cookie : header-hash : full-hash
>>
>>A packet thus protected could be triaged efficiently based on the
>>cookie, and only cookie-spoofers could generate load on the header-hash
>>level check.
> 
> I think the sort of mechanism I described represents a more secure 
> foundation for the multi-layered defense we need. It is a 
> cookie-style scheme in a sense, with no need for a hash to tie the 
> cookie to any part of a packet, and thus it is more efficient and 
> less prone to DoS.

I don't care much about the specifics of the cookie algorithm - I'll let
others propose those. But I don't see how what you've discussed above is
different from what I proposed, other than I'm trying to use multiple
strengths within layers of use of a single protocol (IPsec, in this
case), whereas you are proposing entirely new protocols (??).

>>Again, this argues for a variety of strengths of algorithms, which is
>>what FASTsec (the other half of what I proposed originally) is aimed at,
>>and which I continue to pursue outside the IETF (if anyone is interested)...
> 
> I think your proposal for faster algorithms of various strengths is 
> another possible avenue, but it results in a more complex secure 
> analysis when one tries to figure out what level of protection is 
> afforded. By separating the rate-limiting mechanism from the 
> authentication and integrity mechanisms we get an easier to 
> understand set of security mechanisms, each of which can be evaluated 
> independently for its targeted purpose.

Can you explain more about separating rate-limiting from authen/integ
mechanisms? Where is the rate limiting? (in 'IKE' or its equivalent?)

Joe

_______________________________________________