Re: Tagging or rate limiting: please consider another ML and a BOF (was Re: next task, applicability statement)

Pekka Nikander wrote:
> Dear Stephen and Joe,
> 
> While I find your recent discussion at the BTNS WG mailing
> list interesting, I also think that a large part of it does
> not belong to this WG.  Some of the issues seems be of
> relevance, and most probably should be recorded somewhere in
> the forthcoming applicability document.

Those two statements seem inconsistent; if it's part of the AS, then we
need to vet it out on this list, though it would be useful to hear other
viewpoints as well.

> However, what comes to the proposal to create a new protocol,
> or variant of AH or ESP, that would provide some kind of an
> early lightweight verification (tagging or cookies) to be
> performed before AH or ESP integrity verification, that clearly
> falls outside the scope of this WG, as I think you duly noted.
> On the other hand, personally I find the proposal quite
> interesting, and would suggest creating another mailing list
> for it, and perhaps trying to schedule a BOF for either Paris
> or Vancouver.  Hence, my co-chair allowing, I think that we can
> continue this discussion here *temporarily*, until such a new
> mailing list has been set up.

I'd be glad to set that up at postel.org, if there is a good name for
such a list - maybe "triage"?

> I think the included message below nicely highlights the points
> that you both have in this regard, and might function well as
> a starting point for such a discussion.  What comes to the
> architectural difficulties w.r.t. IPsec, to me it seems that
> there are such difficulties if you take rfc2401(bis) as such.
> On the other hand, I think I understand Joe's desire to add
> this kind of a new protection as a part of IPsec, and perhaps
> re-use some of the existing security mechanisms.
> 
> Maybe there could be a middle path, where we would add a new
> "sublayer" to the IPsec mechanisms?  Perhaps the new sublayer
> could re-use the SPD and PAD but have an independent SAD, and
> hence could be more easily implemented on separate hardware.
> 
> Perhaps something like the following:
> 
>                         Unprotected
>                           ^       ^
>                           |       |
>             +-------------|-------|-------+
>             |             |       |       |
>             |             |       v       |
>             |             |   +--------+  |
>             |     +-----------| Prot.X |  |
>             |     |       |   +--------+  |
>             |     v       |       ^       |
>             | +-------+   |       |       |
>             | |Discard|<--|       V       |
>             | +-------+   |B  +--------+  |
>           ................|y..| AH/ESP |..... IPsec Boundary
>             |   +---+     |p  +--------+  |
>             |   |IKE|<----|a      ^       |
>             |   +---+     |s      |       |
>             | +-------+   |s      |       |
>             | |Discard|<--|       |       |
>             | +-------+   |       |       |
>             +-------------|-------|-------+
>                           |       |
>                           V       V
>                           Protected
> 
> 
> --Pekka
> 
> 
> On Jun 3, 2005, at 19:34, Joe Touch wrote:
> 
> 
> 
> 
> Stephen Kent wrote:
> ...
> 
>>>But a deeper issue is why you - a security person - don't see rate
>>>limitng as a security mechanism. Pure rate limiting isn't security, 
>>>but
>>>rate limiting based on a cookie - or dynamic variant thereof - IS. 
>>>Which
>>>is why I feel it would be better developed as an alternate algorithm 
>>>in
>>>the IPsec suite than as a completely separate protocol that
>>>recapitulates IPsec.
> 
>>I have characterized rate limiting of the sort I described as a
>>security service, but one that is fundamentally different from
>>watered down integrity checking. So your first sentence above makes
>>no sense to me.
> 
> Blind rate limiting is easy to implement, but impacts legitimate peers.
> Differential rate limiting needs to separate traffic from legitimate
> (with some false positives) traffic from non-legitimate (with no false
> negatives).
> 
> IMO, differential rate limiting is a continuum, both in terms of the
> rates limited to (full down to zero) and the strength of separation
> (legitimate + false positives down to no false positives). Current 
> IPsec
> is one configuration of that set of knobs.
> 
> I.e,, ESP rate limits to 0 for things that fail SPI lookup, fail to
> decrypt/authenticate, or fail to match ports, and "unlimits" the rate
> for things that suceed.
> 
> There are certainly uses to other 'rates' than 100% and 0%, but IMO the
> utility for reducing DOS impact is to use low-cost algorithms that have
> higher percentages of false positives.
> 
> 
>>Adding the sort of rate limiting I described to IPsec as a separate
>>protocol, in addition to AH and ESP, could be done. It would not be a
>>complementary algorithm, analogous to HMAC or AES, which are choices
>>for integrity and confidentiality. The service is intrinsically
>>different from those that we now offer, so referring to is as an
>>alternate algorithm confuses matters.
> 
> IMO, it's just an algorithm of AH or ESP, just one that is weaker, 
> e.g.,
> MD4, down to ones closer to 'null'.
> 
> The current modes of IPsec already provide completely different
> capabiltiies (integrity vs. encryption), and provide different 
> strengths
> of algs (MD5 being 'crackable', AES slower but no known cracks, etc.)
> 
> 
>>For example, we could create a new protocol, X, that one views as
>>part of IPsec, and which effects the crypto-based rate limiting I
>>described. The choice of algorithm for X becomes a matter of
>>selecting a PRNG. The protocol would define a format for carrying the
>>tag (or cookie, as you wish), and the procedures for verifying that
>>the tag was valid, which includes rejecting replays and accommodating
>>out of order packet arrival.
> 
> If the format for carrying the tags is similar - as with integrity and
> encryption - we don't need a new tag format.
> 
> 
>>But, what would we have done, relative to the router management
>>problem that we have discussed? If we say that X is another protocol
>>in the IPsec suite, that where is it implemented in the router? If it
>>is in the management processor, which I still maintain is the
>>appropriate place for IPsec when used to protect BGP traffic, then we
>>have not solved the problem, since if the traffic gets that far it is
>>already too late.  This suggests that protocol X has to be
>>implemented on a line card, to be effective. That's fine, but it
>>suggests some potential complexity for IPsec since we have now
>>required the implementation to be divided across the management
>>processor and each line card, by making X part of IPsec. Also, if one
>>wants integrity and authentication, not just the rate limiting
>>service, one will need to use ESP or AH, and there will be two layers
>>of IPsec protocols, since X is part of IPsec. TYhis adds complexity
>>to SPD management, and raises the question of how to maintain the
>>SAD, since it nominally needs to be accessed in both the line cards
>>and the management processor.
> 
> I agree that there are complexities, but they remain whether there are
> two protocols or one. If one, then we can describe how to manage the
> complexities more easily.
> 
> I do believe that if IPsec is going to be used widely in routers -
> either for management traffic or as VPN endpoints - this sort of
> capability is needed anyway.
> 
> 
>>So, unless we implemented IPsec on each line card, in which case we
>>might not need the rate limiting service, making protocol X part of
>>IPsec probably results in a very complex implementation. It also
>>raises questions about how to define the IPsec boundary which now
>>appears to be distributed across the router in various locations.
> 
> IPsec on each line card still needs rate limiting to be widely 
> deployed;
> line-rate IPsec is expensive at best; using a variety of algorithms
> would allow the cost to be reduced.
> 
> 
>>If, on the other hand, one addresses rate limiting with an IP option,
>>for the steady state part of the problem, then many of these
>>complications would not arise, and could make use of a simple IPsec
>>implementation in the management processor.
> 
> My point is that the IP option solution is basically re-doing all of
> IPsec - the databases, the key exchange protocol, even most of the
> header formats, since we can't assume free option space in which to
> operate. I see no reason to develop a new protocol that needs to be 
> just
> as coordinated with the internal IPsec anyway.
> 
> Joe
_______________________________________________

> _______________________________________________