From Internet-Drafts at ietf.org Tue Jul 5 12:50:01 2005 From: Internet-Drafts at ietf.org (Internet-Drafts@ietf.org) Date: Tue, 05 Jul 2005 15:50:01 -0400 Subject: [anonsec] I-D ACTION:draft-ietf-btns-prob-and-applic-00.txt Message-ID: ENCODING mime FILE /internet-drafts/draft-ietf-btns-prob-and-applic-00.txt -------------- next part -------------- From touch at ISI.EDU Tue Jul 5 14:54:17 2005 From: touch at ISI.EDU (Joe Touch) Date: Tue, 05 Jul 2005 14:54:17 -0700 Subject: [anonsec] Tagging or rate limiting: please consider another ML and a BOF (was Re: next task, applicability statement) In-Reply-To: <6edf2f56d1b70d6cb1a33ad556e677a9@nomadiclab.com> References: <20050511220423.GN22993@binky.Central.Sun.COM> <20050512173814.GY22993@binky.Central.Sun.COM> <87e75ea679bf554da3aef66eee4533cc@nomadiclab.com> <20050531231134.GX20324@binky.Central.Sun.COM> <429E19B8.9080507@isi.edu> <429F329E.6030102@isi.edu> <429F5B7A.5080700@isi.edu> <429F82E8.2010600@isi.edu> <42A08699.80205@isi.edu> <6edf2f56d1b70d6cb1a33ad556e677a9@nomadiclab.com> Message-ID: <42CB0189.4020301@isi.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, all, As per Pekka's suggestion (below), a separate mailing list has been created for discussions of tagging/rate limiting issues: triage at postel.org The website is http://www.postel.org/triage/ FYI. Joe 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. > > 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 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 _______________________________________________ > _______________________________________________ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCywGIE5f5cImnZrsRAuyBAKDx1xTMfbAqRkzfGOoggi0fbqD7RgCgy+kc Uwd822b9pFm61SajAnC4BUU= =2dFm -----END PGP SIGNATURE----- From lha at it.su.se Mon Jul 25 06:43:36 2005 From: lha at it.su.se (=?iso-8859-1?q?Love_H=F6rnquist_=C5strand?=) Date: Mon, 25 Jul 2005 15:43:36 +0200 Subject: [anonsec] Agenda for IETF63 Message-ID: A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 477 bytes Desc: not available Url : http://www.postel.org/pipermail/anonsec/attachments/20050725/84f139b2/attachment.bin