Re: next task, applicability statement

Stephen Kent wrote:
> Joe,
> ...
> 
>>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.
> 
> If that's what you meant, it was not at all clear to me. Even the 
> text you provided above talks about renegotiating cookies via IKE, 
> rather than negotiating a shared secret used to generate a sequence 
> of cookies. Maybe the problem we have trying to communicate, Joe, is 
> translating between the terminology used in the security community to 
> describe mechanisms and the terms of the sort you were using.

As I said, the details of the cookie algorithm aren't important to me
per se; they could be static cookies negotiated by IKE, renegotiated by
IKE, or follow some sequence as you suggest.

It's not a matter of terminology as apathy - I want support for a
variety of these algorithms.

>> > 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.
> 
> What you refer to as a static cookie is not only not secure if an 
> attacker can wiretap a link, but it also provides much less 
> protection, on a bit by bit basis, because it is unchanging, as 
> compared to a sequence of pseudo-random values.

Yes, we all know that, but that sort of 'cookie' is basically what the
IP address and port pairs provide. It's similar enough to what the TCP
RST provides as well. The point isn't whether that's insecure for
on-path attacks, but whether it's low-effort and can help distinguish
packets for a preliminary level of triage.

Further, the cookie space can be larger than the IP address/port pair,
because it is decoupled from them.

It's not the only solution, but one of a variety that could be used,
depending on the threat model.

>>And agreed, IKE needs to be rate-limited as well.
> 
> yes, whatever mechanism one uses for distribution and refresh of 
> shared secrets needs to be rate limited, but that is an easier 
> problem if the set of peers is limited and known a priori, as is 
> typically the case for management traffic. (This of course is not the 
> case for the BTNS context, where peers are not known a priori, and 
> are not authenticated.) the mechanisms for rate limiting here are 
> different, because you are not dealing with steady state 
> communication.

Doens't IKE need to be rate limited anyway? How does it matter if I know
the peers; I can still be flooded by attackers. Unless the 'permitted
peer' traffic is filtered based on IP addresses and ports, at which
point that's a cookie filter that works only for off-path attacks.

BTNS doesn't open up a hole with respect to IKE attacks; the number of
connections admitted can - and should - be limited anyway, just as it
would for a conventional IKE endpoint that is configured for a large
number of legitimate peers. There's still triage at some point either way.

>> > 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.
> 
> I distinctly recall you dismissing MITM attacks as part of the range 
> of attacks that BTNS was intended to address, at the BoF, so I'm 
> puzzled by this comment.

MITM != on-path

MITM during the key exchange is what I dismissed. That's substantially
harder than just viewing packets on-path and injecting packets; there
are timing issues for MITM during key exchange to succeed.

>>However, the above is again why I believe the generic capability for
>>lower-quality algorithms is needed, independent of where.
> 
> You have not provided a concrete example (that others have agreed 
> with) to justify your suggestion for an algorithmically watered down 
> IPsec. Since this topic is not within scope for BTNS, I suggest we 
> not pursue it further.

The concrete example is what you brought up - ISPs that don't want to
deploy IPsec because it provides a CPU-loading DOS attack. The solution
is to use any of a variety of watered-down algorithms within IPsec's
protocol.

I agreed that this wasn't within scope for BTNS when it was raised in
San Diego, and agree that it isn't worth pursuing - either within this
WG at this time, or as a reason not to use IPsec within this WG at this
time either.

>>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.
> 
> I'm sorry, Joe, but you seem to be missing the point. rate limiting 
> traffic in a bandwidth or computationally constrained context is a 
> specialized security function that is not best addressed by watering 
> down the crypto algorithms used with a security protocol, since such 
> watering down degrades the other security services offered by the 
> protocol.

I don't buy that assertion; IPsec allows a variety of algorithms, not
all with the same strength. This is just a different set of algorithms
which can provide different computational effort and different
protection, just as 3DES is different from DES.

>> >>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 (??).
> 
> Yes, it seems from the text above that you didn't understand what I 
> proposed, and thus have trouble distinguishing it from mechanisms 
> that perform crypto binding of cookies to headers, etc.

As I've repeatedly said, the algorithm isn't the point; it's the
variety of algorithms that matters. IPsec already had two variants that
treated headers differently (AH and ESP), this would be a third (or
fourth, etc.).

There's no need to develop an entirely new framework in which to acheive
this - ESPECIALLY since, in order to be useful, the triage must occur
before stronger (e.g., 3DES) conventional IPsec. Which means it either
has to be inside the IPsec framework, or has to be at the IP level and
supercede it.

>> >>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?)
> 
> IKE, IPsec, and other security protocols we have developed in the 
> IETF do NOT focus on rate limiting traffic in a computationally 
> efficient fashion, so your second question is inappropriate.

It's not my question, it was the ISPs. If you can't rate limit IPsec,
you have to rate limit a header outside of IPsec.

> The purpose of rate limiting is provide a very fast check on an 
> arriving packet, so that a receiver need not apply more expensive 
> checks at a rate higher than the rate at which peers send legitimate 
> traffic.

We all know the definition, but all such checks are relative. DES is a
rate limit check on 3DES.

Joe