From pekka.nikander at nomadiclab.com Wed Jun 1 05:34:36 2005 From: pekka.nikander at nomadiclab.com (Pekka Nikander) Date: Wed, 1 Jun 2005 15:34:36 +0300 Subject: [anonsec] what kind of phase 2 SAs are we negotiating? In-Reply-To: <20050527152942.GZ1287@binky.Central.Sun.COM> References: <20050408173500.GD5837@binky.Central.Sun.COM> <0ca22089ca25525e102aa8716441aa1f@nomadiclab.com> <20050527152246.GH28920@binky.Central.Sun.COM> <20050527152942.GZ1287@binky.Central.Sun.COM> Message-ID: <195562d03735dc684d53d1d022362dd2@nomadiclab.com> >> On Fri, May 27, 2005 at 12:59:12PM +0300, Pekka Nikander wrote: >>> Given that we are likely to move to an environment where >>> the IP addresses are likely to be quite ephemeral, IMHO >>> there is strong architectural reasons to annotate the >>> incoming IPsec-protected IP packets with the SA, and even >>> have back-pointers from the SA to the relevant SPD and PAD >>> entries. > On Fri, May 27, 2005 at 10:22:46AM -0500, Nicolas Williams wrote: >> I agree, but this won't make the two-nodes-behind-the-same-NAT problem >> that Michael brings up go away as the PAD entry on the server, in that >> case, is for the NAT address, not for the address behind the NAT, so >> we'd have to fix the PAD to be NAT aware. Sigh. Hmm. I don't see any immediate reason why an already existing PAD entry couldn't be "NAT aware" already, but maybe I am missing something here (and see also below). That is, if you index the PAD entries by the identity, i.e., the public key or self signed cert in the BTNS case, couldn't there easily be several PAD entries with child SAs that have overlapping IP address (ranges)? Sure, there might be practical difficulties in creating and maintaining the corresponding SPD entries for outgoing child SA traffic, especially in the case of BIT* implementations. Especially, packets that are sent to a new port at the remote IP address are likely to go to a wrong host or nowhere at all, but that is nothing new with NATs. That would happen even if you did not use IPsec. On May 27, 2005, at 18:29, Nicolas Williams wrote: > And note that there is a compatibility/authorization problem here. > > Suppose I have an application that uses KAME's IP_POLICY socket option > and assumes that the IP addresses of connected sockets with that option > set have been strongly authenticated and so it does authorization > checks > based on IP addresses? I would argue that such an application would be fundamentally flawed. If it did use socket options to gain authentication/authorisation information, it should not automatically assume that other sockets bound to the same IP address *necessarily* share the same authorisation information. Even if there was no NATs, there may be per-port SPD entries making the assumption wrong. Hence, I would be tended to claim that such an application would not conform to the IPsec architecture, but maybe I'm wrong here. > I don't know of any such applications, but, do none such exist? Neither do I know any such applications... --Pekka From kent at bbn.com Wed Jun 1 08:37:53 2005 From: kent at bbn.com (Stephen Kent) Date: Wed, 1 Jun 2005 11:37:53 -0400 Subject: [anonsec] next task, applicability statement In-Reply-To: <20050531231134.GX20324@binky.Central.Sun.COM> References: <20050511220423.GN22993@binky.Central.Sun.COM> <20050512173814.GY22993@binky.Central.Sun.COM> <87e75ea679bf554da3aef66eee4533cc@nomadiclab.com> <20050531231134.GX20324@binky.Central.Sun.COM> Message-ID: At 6:11 PM -0500 5/31/05, Nicolas Williams wrote: >On Tue, May 31, 2005 at 10:45:37AM -0400, Stephen Kent wrote: >[...] >> The answer was mixed, in that some ISPs use MD5, and other do not. >> Among those who do not, the primary reason cited as NOT the >> administrative burden of managing the keys (in the absence of an >> automated key management scheme), but rather the fear that use of the >> scheme created a DoS vulnerability for routers. Specifically, an >> attacker could send a moderate amount of bogus traffic that claimed >> to be for an MD5 protected BGP session, and this would invoke the >> additional computational burden associated with such protection. This >> perception on the part of network operators suggests that use of >> IPsec for this purpose is not going to be any more palatable than >> MD5, unless we have good arguments to counter the DoS concern cited >> by these operators. > >[...] > >> I mention this because one of the major motivations cited by Joe in >> the BOF was precisely protecting e-BGP sessions against active >> attacks, e.g., resets. > >It was, yes, but there are other uses too, plus use between routers has >hardly been ruled out. Surely you don't think we should just conclude >this WG and go home... > >Nico >-- 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. Steve From kent at bbn.com Wed Jun 1 08:37:23 2005 From: kent at bbn.com (Stephen Kent) Date: Wed, 1 Jun 2005 11:37:23 -0400 Subject: [anonsec] next task, applicability statement In-Reply-To: <429CECC5.4060107@isi.edu> References: <20050511220423.GN22993@binky.Central.Sun.COM> <20050512173814.GY22993@binky.Central.Sun.COM> <87e75ea679bf554da3aef66eee4533cc@nomadiclab.com> <429CECC5.4060107@isi.edu> Message-ID: Joe, >If IPsec processing cannot be offloaded to line cards and run at rate, >then it is doomed as a security mechanism. There are many places in a network where one may choose to employ IPsec, with different benefits. Routers have not been designed to run IPsec on line cards, and this is not surprising. I would not criticize either IPsec nor router vendors for the current state of affairs. After all, IPsec was not proposed as a hop-by-hop protection mechanism for subscriber traffic. Although we made accommodations in 2401bis to allow such use in overlay nets, largely at your insistence, that is not a primary application of IPsec. >This is why I originally >proposed investigating ways to make IPsec less strong but keep pace with >line rate, without overloading the processor, but that was nixed by a >number of parties in San Diego. My recollection is that several folks said that the performance arguments put forth for why IPsec was not more widely deployed did not match their experience as implementors. I think it fair to say that the issue here is one of economics, not fundamental technical issues. Line cards come in various flavors and contribute substantially to the overall cost of a router, today. Since most routers are sold to enterprise (not ISP) customers, it's hard to argue why inclusion of IPsec on line cards is attractive to these customers. >All competing solutions - the RST/ACK challenge being proposed in TCPM, >TTL-225, even assuming SPI values can substantially help filter - all >are equivalent to weaker encryption algorithms, where the weakest is a >"cookie" that must be guessed, next are cookies in ranges, etc. I agree that the underlying threat model being assumed here is one in which the attacker does not have passive or active wiretap capabilities for the link between a pair of routers. I have argued that this is not a good basis for security standards, but that is the model adopted by the ISPs. Remember, I have proposed use of IPsec as a component of the S-BGP architecture for several years, so this is not the sort of response from ISPs that I like to hear. But, I am passing it on because it was a clear message at this workshop, and relevant to one of the cited motivations for choosing IPsec as the protocol to be adapted to accommodate BTNS requirements. Steve -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.postel.org/pipermail/anonsec/attachments/20050601/8b167e9c/attachment.html From Nicolas.Williams at sun.com Wed Jun 1 08:59:28 2005 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Wed, 1 Jun 2005 10:59:28 -0500 Subject: [anonsec] what kind of phase 2 SAs are we negotiating? In-Reply-To: <195562d03735dc684d53d1d022362dd2@nomadiclab.com> References: <20050408173500.GD5837@binky.Central.Sun.COM> <0ca22089ca25525e102aa8716441aa1f@nomadiclab.com> <20050527152246.GH28920@binky.Central.Sun.COM> <20050527152942.GZ1287@binky.Central.Sun.COM> <195562d03735dc684d53d1d022362dd2@nomadiclab.com> Message-ID: <20050601155928.GF20324@binky.Central.Sun.COM> On Wed, Jun 01, 2005 at 03:34:36PM +0300, Pekka Nikander wrote: > > On Fri, May 27, 2005 at 10:22:46AM -0500, Nicolas Williams wrote: > >> I agree, but this won't make the two-nodes-behind-the-same-NAT problem > >> that Michael brings up go away as the PAD entry on the server, in that > >> case, is for the NAT address, not for the address behind the NAT, so > >> we'd have to fix the PAD to be NAT aware. Sigh. > > Hmm. I don't see any immediate reason why an already existing > PAD entry couldn't be "NAT aware" already, but maybe I am missing > something here (and see also below). That is, if you index the > PAD entries by the identity, i.e., the public key or self signed > cert in the BTNS case, couldn't there easily be several PAD entries > with child SAs that have overlapping IP address (ranges)? [...] Ah, yes, non-IP address IDs are allowed as indexes. > On May 27, 2005, at 18:29, Nicolas Williams wrote: > > And note that there is a compatibility/authorization problem here. > > > > Suppose I have an application that uses KAME's IP_POLICY socket option > > and assumes that the IP addresses of connected sockets with that option > > set have been strongly authenticated and so it does authorization > > checks > > based on IP addresses? > > I would argue that such an application would be fundamentally flawed. So would I. The question is though, do such applications exist and did they every have a hope of being reasonably secure modulo policy configuration? If the answer is yes to both parts of that question then we have to consider backwards compatibility, though we can probably handle that as a security consideration, something like "don't turn this on if you know it would break an application with flawed assumptions about IPsec." > If it did use socket options to gain authentication/authorisation > information, it should not automatically assume that other sockets > bound to the same IP address *necessarily* share the same authorisation > information. Even if there was no NATs, there may be per-port SPD > entries > making the assumption wrong. Hence, I would be tended to claim that > such an application would not conform to the IPsec architecture, > but maybe I'm wrong here. I agree, but such an application could be relying on local policy configuration to ensure the behaviour that the application expects. > > I don't know of any such applications, but, do none such exist? > > Neither do I know any such applications... Good. Nico -- From Nicolas.Williams at sun.com Wed Jun 1 09:05:05 2005 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Wed, 1 Jun 2005 11:05:05 -0500 Subject: [anonsec] next task, applicability statement In-Reply-To: References: <20050511220423.GN22993@binky.Central.Sun.COM> <20050512173814.GY22993@binky.Central.Sun.COM> <87e75ea679bf554da3aef66eee4533cc@nomadiclab.com> <20050531231134.GX20324@binky.Central.Sun.COM> Message-ID: <20050601160504.GG20324@binky.Central.Sun.COM> On Wed, Jun 01, 2005 at 11:37:53AM -0400, Stephen Kent wrote: > At 6:11 PM -0500 5/31/05, Nicolas Williams wrote: > >On Tue, May 31, 2005 at 10:45:37AM -0400, Stephen Kent wrote: > >[...] > >> I mention this because one of the major motivations cited by Joe in > >> the BOF was precisely protecting e-BGP sessions against active > >> attacks, e.g., resets. > > > >It was, yes, but there are other uses too, plus use between routers has > >hardly been ruled out. Surely you don't think we should just conclude > >this WG and go home... > > > >Nico > >-- > > 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. I was asking for BTNS-like IPsec features long before the first ANONSEC BoF. The ANONSEC BoF had good timing, it brought together groups with different uses for the same idea and reached critical mass. Nico -- From kent at bbn.com Wed Jun 1 10:09:01 2005 From: kent at bbn.com (Stephen Kent) Date: Wed, 1 Jun 2005 13:09:01 -0400 Subject: [anonsec] next task, applicability statement In-Reply-To: <20050601160504.GG20324@binky.Central.Sun.COM> References: <20050511220423.GN22993@binky.Central.Sun.COM> <20050512173814.GY22993@binky.Central.Sun.COM> <87e75ea679bf554da3aef66eee4533cc@nomadiclab.com> <20050531231134.GX20324@binky.Central.Sun.COM> <20050601160504.GG20324@binky.Central.Sun.COM> Message-ID: Nico, > >I was asking for BTNS-like IPsec features long before the first ANONSEC >BoF. > >The ANONSEC BoF had good timing, it brought together groups with >different uses for the same idea and reached critical mass. > >Nico Yes, I agree. I noted to Sam at the close of the BoF, there appeared to be three different groups who wanted some set of overlapping features in IPsec to satisfy different criteria. Steve From touch at ISI.EDU Wed Jun 1 13:19:24 2005 From: touch at ISI.EDU (Joe Touch) Date: Wed, 01 Jun 2005 13:19:24 -0700 Subject: [anonsec] next task, applicability statement In-Reply-To: References: <20050511220423.GN22993@binky.Central.Sun.COM> <20050512173814.GY22993@binky.Central.Sun.COM> <87e75ea679bf554da3aef66eee4533cc@nomadiclab.com> <429CECC5.4060107@isi.edu> Message-ID: <429E184C.6010800@isi.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Stephen Kent wrote: > Joe, > >> If IPsec processing cannot be offloaded to line cards and run at rate, >> then it is doomed as a security mechanism. > > There are many places in a network where one may choose to employ IPsec, > with different benefits. Routers have not been designed to run IPsec on > line cards, and this is not surprising. Cisco makes modules that, while not on line cards themselves, are implemented in hardware (IPsec Services Modules). > I would not criticize either > IPsec nor router vendors for the current state of affairs. After all, > IPsec was not proposed as a hop-by-hop protection mechanism for > subscriber traffic. Although we made accommodations in 2401bis to allow > such use in overlay nets, largely at your insistence, that is not a > primary application of IPsec. The issue of hop-by-hop ala RFC3884 is not related to BTNS; it wasn't even cited in the original ANONsec ID. e-BGP isn't hop-by-hop, it is communication TO the router, which is already covered in 2401, since the host is terminating the traffic to a local application and is thus acting as a host. >> This is why I originally >> proposed investigating ways to make IPsec less strong but keep pace with >> line rate, without overloading the processor, but that was nixed by a >> number of parties in San Diego. > > My recollection is that several folks said that the_ performance_ > arguments put forth for why IPsec was not more widely deployed did not > match their experience as implementors. I think it fair to say that the > issue here is one of economics, not fundamental technical issues. Line > cards come in various flavors and contribute substantially to the > overall cost of a router, today. Since most routers are sold to > enterprise (not ISP) customers, it's hard to argue why inclusion of > IPsec on line cards is attractive to these customers. Which is exactly why it would be useful to have low-cost (low-CPU power, etc.) IPsec variants. >> All competing solutions - the RST/ACK challenge being proposed in TCPM, >> TTL-225, even assuming SPI values can substantially help filter - all >> are equivalent to weaker encryption algorithms, where the weakest is a >> "cookie" that must be guessed, next are cookies in ranges, etc. > > I agree that the underlying threat model being assumed here is one in > which the attacker does not have passive or active wiretap capabilities > for the link between a pair of routers. I have argued that this is not a > good basis for security standards, but that is the model adopted by the > ISPs. Remember, I have proposed use of IPsec as a component of the S-BGP > architecture for several years, so this is not the sort of response from > ISPs that I like to hear. But, I am passing it on because it was a clear > message at this workshop, and relevant to one of the cited motivations > for choosing IPsec as the protocol to be adapted to accommodate BTNS > requirements. That latter issue is moot; the reality is that IPsec is a good place to develop BTNS for a variety of reasons independent of whether the result is the more widely deployable compared to other protocols that might be extended, as noted by Sam in Minneapolis when you raised this objection before. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCnhhME5f5cImnZrsRAoS0AKDTyEr+N4YKpfJt9khbT0m0vAZlKACgs45V Wt3uzHWiWh78t5hqUDavq0c= =O6tj -----END PGP SIGNATURE----- From touch at ISI.EDU Wed Jun 1 13:25:28 2005 From: touch at ISI.EDU (Joe Touch) Date: Wed, 01 Jun 2005 13:25:28 -0700 Subject: [anonsec] next task, applicability statement In-Reply-To: References: <20050511220423.GN22993@binky.Central.Sun.COM> <20050512173814.GY22993@binky.Central.Sun.COM> <87e75ea679bf554da3aef66eee4533cc@nomadiclab.com> <20050531231134.GX20324@binky.Central.Sun.COM> Message-ID: <429E19B8.9080507@isi.edu> -----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. A multilevel solution, with different levels of effort, would be (as always) useful. 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. 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)... Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCnhm4E5f5cImnZrsRAolRAJwOnDZkXbswnsSViGFmA/l+7f83nQCg5WU6 ya6EgkTZeCtErT5/mDMobbI= =MdzZ -----END PGP SIGNATURE----- From kent at bbn.com Thu Jun 2 08:34:50 2005 From: kent at bbn.com (Stephen Kent) Date: Thu, 2 Jun 2005 11:34:50 -0400 Subject: [anonsec] next task, applicability statement In-Reply-To: <429E184C.6010800@isi.edu> References: <20050511220423.GN22993@binky.Central.Sun.COM> <20050512173814.GY22993@binky.Central.Sun.COM> <87e75ea679bf554da3aef66eee4533cc@nomadiclab.com> <429CECC5.4060107@isi.edu> <429E184C.6010800@isi.edu> Message-ID: At 1:19 PM -0700 6/1/05, Joe Touch wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > > > >Stephen Kent wrote: >> Joe, >> >>> If IPsec processing cannot be offloaded to line cards and run at rate, >>> then it is doomed as a security mechanism. >> >> There are many places in a network where one may choose to employ IPsec, >> with different benefits. Routers have not been designed to run IPsec on >> line cards, and this is not surprising. > >Cisco makes modules that, while not on line cards themselves, are >implemented in hardware (IPsec Services Modules). yes, and there are good economic reasons that they are not on line cards. > > I would not criticize either >> IPsec nor router vendors for the current state of affairs. After all, >> IPsec was not proposed as a hop-by-hop protection mechanism for >> subscriber traffic. Although we made accommodations in 2401bis to allow >> such use in overlay nets, largely at your insistence, that is not a >> primary application of IPsec. > >The issue of hop-by-hop ala RFC3884 is not related to BTNS; it wasn't >even cited in the original ANONsec ID. But it the reason you seem to allude to in arguing that line-card implementations of IPsec are important. > >e-BGP isn't hop-by-hop, it is communication TO the router, which is >already covered in 2401, since the host is terminating the traffic to a >local application and is thus acting as a host. > >>> This is why I originally >>> proposed investigating ways to make IPsec less strong but keep pace with >>> line rate, without overloading the processor, but that was nixed by a >>> number of parties in San Diego. >> >> My recollection is that several folks said that the_ performance_ >> arguments put forth for why IPsec was not more widely deployed did not >> match their experience as implementors. I think it fair to say that the >> issue here is one of economics, not fundamental technical issues. Line >> cards come in various flavors and contribute substantially to the >> overall cost of a router, today. Since most routers are sold to >> enterprise (not ISP) customers, it's hard to argue why inclusion of >> IPsec on line cards is attractive to these customers. > >Which is exactly why it would be useful to have low-cost (low-CPU power, >etc.) IPsec variants. As you'll see in my response to your other message, it is not at all clear that weakened variants of IPsec represent a good solution here. > >>> All competing solutions - the RST/ACK challenge being proposed in TCPM, >>> TTL-225, even assuming SPI values can substantially help filter - all >>> are equivalent to weaker encryption algorithms, where the weakest is a >>> "cookie" that must be guessed, next are cookies in ranges, etc. >> >> I agree that the underlying threat model being assumed here is one in >> which the attacker does not have passive or active wiretap capabilities >> for the link between a pair of routers. I have argued that this is not a >> good basis for security standards, but that is the model adopted by the >> ISPs. Remember, I have proposed use of IPsec as a component of the S-BGP >> architecture for several years, so this is not the sort of response from >> ISPs that I like to hear. But, I am passing it on because it was a clear >> message at this workshop, and relevant to one of the cited motivations >> for choosing IPsec as the protocol to be adapted to accommodate BTNS >> requirements. > >That latter issue is moot; the reality is that IPsec is a good place to >develop BTNS for a variety of reasons independent of whether the result >is the more widely deployable compared to other protocols that might be >extended, as noted by Sam in Minneapolis when you raised this objection >before. My objection was valid then, and it is more relevant now because the primary rationale you cited for why IPsec is the right protocol for BTNS turns out to be a questionable assertion. Steve From kent at bbn.com Thu Jun 2 08:01:37 2005 From: kent at bbn.com (Stephen Kent) Date: Thu, 2 Jun 2005 11:01:37 -0400 Subject: [anonsec] next task, applicability statement In-Reply-To: <429E19B8.9080507@isi.edu> 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> Message-ID: 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. 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. 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! > 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. >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. >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. Steve From touch at ISI.EDU Thu Jun 2 09:23:58 2005 From: touch at ISI.EDU (Joe Touch) Date: Thu, 02 Jun 2005 09:23:58 -0700 Subject: [anonsec] next task, applicability statement In-Reply-To: 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> Message-ID: <429F329E.6030102@isi.edu> 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 254 bytes Desc: OpenPGP digital signature Url : http://www.postel.org/pipermail/anonsec/attachments/20050602/998a6df3/signature-0001.bin From touch at ISI.EDU Thu Jun 2 09:35:34 2005 From: touch at ISI.EDU (Joe Touch) Date: Thu, 02 Jun 2005 09:35:34 -0700 Subject: [anonsec] next task, applicability statement In-Reply-To: References: <20050511220423.GN22993@binky.Central.Sun.COM> <20050512173814.GY22993@binky.Central.Sun.COM> <87e75ea679bf554da3aef66eee4533cc@nomadiclab.com> <429CECC5.4060107@isi.edu> <429E184C.6010800@isi.edu> Message-ID: <429F3556.2010301@isi.edu> Stephen Kent wrote: > At 1:19 PM -0700 6/1/05, Joe Touch wrote: > >>-----BEGIN PGP SIGNED MESSAGE----- >>Hash: SHA1 >> >>Stephen Kent wrote: >> >>> Joe, >>> >>> >>>> If IPsec processing cannot be offloaded to line cards and run at rate, >>>> then it is doomed as a security mechanism. >>> >>> There are many places in a network where one may choose to employ IPsec, >>> with different benefits. Routers have not been designed to run IPsec on >>> line cards, and this is not surprising. >> >>Cisco makes modules that, while not on line cards themselves, are >>implemented in hardware (IPsec Services Modules). > > yes, and there are good economic reasons that they are not on line cards. Agreed, but when ISPs need the protection, there will be economic reasons to include them, eventually. Just as forwarding moved onto line cards, though not economical at first. >> > I would not criticize either >>> IPsec nor router vendors for the current state of affairs. After all, >>> IPsec was not proposed as a hop-by-hop protection mechanism for >>> subscriber traffic. Although we made accommodations in 2401bis to allow >>> such use in overlay nets, largely at your insistence, that is not a >>> primary application of IPsec. >> >>The issue of hop-by-hop ala RFC3884 is not related to BTNS; it wasn't >>even cited in the original ANONsec ID. > > But it the reason you seem to allude to in arguing that line-card > implementations of IPsec are important. I'm arguing that line cards are the input of packets - whether forwarded or not, and that security triage needs to occur as early as possible. That is irrespective of whether the packets are ultimately forwarded (RFC3884) or terminated (e-BGP). >>e-BGP isn't hop-by-hop, it is communication TO the router, which is >>already covered in 2401, since the host is terminating the traffic to a >>local application and is thus acting as a host. >> >> >>>> This is why I originally >>>> proposed investigating ways to make IPsec less strong but keep pace with >>>> line rate, without overloading the processor, but that was nixed by a >>>> number of parties in San Diego. >>> >>> My recollection is that several folks said that the_ performance_ >>> arguments put forth for why IPsec was not more widely deployed did not >>> match their experience as implementors. I think it fair to say that the >>> issue here is one of economics, not fundamental technical issues. Line >>> cards come in various flavors and contribute substantially to the >>> overall cost of a router, today. Since most routers are sold to >>> enterprise (not ISP) customers, it's hard to argue why inclusion of >>> IPsec on line cards is attractive to these customers. >> >>Which is exactly why it would be useful to have low-cost (low-CPU power, >>etc.) IPsec variants. > > As you'll see in my response to your other message, it is not at all > clear that weakened variants of IPsec represent a good solution here. What you described elsewhere are weakend variants of IPsec that just don't use the IPsec header structure. Do we really need another structure just for this purpose? >>>> All competing solutions - the RST/ACK challenge being proposed in TCPM, >>>> TTL-225, even assuming SPI values can substantially help filter - all >>>> are equivalent to weaker encryption algorithms, where the weakest is a >>>> "cookie" that must be guessed, next are cookies in ranges, etc. >>> >>> I agree that the underlying threat model being assumed here is one in >>> which the attacker does not have passive or active wiretap capabilities >>> for the link between a pair of routers. I have argued that this is not a >>> good basis for security standards, but that is the model adopted by the >>> ISPs. Remember, I have proposed use of IPsec as a component of the S-BGP >>> architecture for several years, so this is not the sort of response from >>> ISPs that I like to hear. But, I am passing it on because it was a clear >>> message at this workshop, and relevant to one of the cited motivations >>> for choosing IPsec as the protocol to be adapted to accommodate BTNS >>> requirements. >> >>That latter issue is moot; the reality is that IPsec is a good place to >>develop BTNS for a variety of reasons independent of whether the result >>is the more widely deployable compared to other protocols that might be >>extended, as noted by Sam in Minneapolis when you raised this objection >>before. > > My objection was valid then, and it is more relevant now because the > primary rationale you cited for why IPsec is the right protocol for > BTNS turns out to be a questionable assertion. I believe there are many things to fix with IPsec, and that BTNS and FASTsec need to both be developed. I further believe that this addresses the concerns of the ISPs you cited. Sure, killing off half of that effort makes the use of IPsec to solve e-BGP failures open to DOS attacks, but so does ANY use of high-effort algorithmic security at any level. By this argument, ANY use of IPsec with the current algorithms is doomed, and thus there's no reason to avoid using IPsec for BTNS, since IPsec itself need not be considered "holy". Joe -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 254 bytes Desc: OpenPGP digital signature Url : http://www.postel.org/pipermail/anonsec/attachments/20050602/f366cb78/signature.bin From Nicolas.Williams at sun.com Thu Jun 2 10:26:55 2005 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Thu, 2 Jun 2005 12:26:55 -0500 Subject: [anonsec] next task, applicability statement In-Reply-To: <429F3556.2010301@isi.edu> References: <20050512173814.GY22993@binky.Central.Sun.COM> <87e75ea679bf554da3aef66eee4533cc@nomadiclab.com> <429CECC5.4060107@isi.edu> <429E184C.6010800@isi.edu> <429F3556.2010301@isi.edu> Message-ID: <20050602172655.GA27456@binky.Central.Sun.COM> On Thu, Jun 02, 2005 at 09:35:34AM -0700, Joe Touch wrote: > Stephen Kent wrote: > > At 1:19 PM -0700 6/1/05, Joe Touch wrote: > >>Cisco makes modules that, while not on line cards themselves, are > >>implemented in hardware (IPsec Services Modules). > > > > yes, and there are good economic reasons that they are not on line cards. > > Agreed, but when ISPs need the protection, there will be economic > reasons to include them, eventually. Just as forwarding moved onto line > cards, though not economical at first. BTNS has several target consumers/uses as identified at the BoFs. Stephen claims some of these don't want BTNS today, but that seems hardly settled, nor is there reason yet to think that they won't want BTNS later. I see no reason yet not to proceed with an applicability statement that mentions the use of BTNS by routers to protect BGP TCP sessions against off-path attacks against TCP (and therefore BGP). Nico -- From kent at bbn.com Thu Jun 2 10:53:01 2005 From: kent at bbn.com (Stephen Kent) Date: Thu, 2 Jun 2005 13:53:01 -0400 Subject: [anonsec] next task, applicability statement In-Reply-To: <20050602172655.GA27456@binky.Central.Sun.COM> References: <20050512173814.GY22993@binky.Central.Sun.COM> <87e75ea679bf554da3aef66eee4533cc@nomadiclab.com> <429CECC5.4060107@isi.edu> <429E184C.6010800@isi.edu> <429F3556.2010301@isi.edu> <20050602172655.GA27456@binky.Central.Sun.COM> Message-ID: At 12:26 PM -0500 6/2/05, Nicolas Williams wrote: >On Thu, Jun 02, 2005 at 09:35:34AM -0700, Joe Touch wrote: >> Stephen Kent wrote: >> > At 1:19 PM -0700 6/1/05, Joe Touch wrote: >> >>Cisco makes modules that, while not on line cards themselves, are >> >>implemented in hardware (IPsec Services Modules). >> > >> > yes, and there are good economic reasons that they are not on line cards. >> >> Agreed, but when ISPs need the protection, there will be economic >> reasons to include them, eventually. Just as forwarding moved onto line >> cards, though not economical at first. > >BTNS has several target consumers/uses as identified at the BoFs. > >Stephen claims some of these don't want BTNS today, but that seems >hardly settled, nor is there reason yet to think that they won't want >BTNS later. I see no reason yet not to proceed with an applicability >statement that mentions the use of BTNS by routers to protect BGP TCP >sessions against off-path attacks against TCP (and therefore BGP). > >Nico The use of the term "claim" here is pejorative, suggesting that I may be misrepresenting the facts. I reported what a set of ISPs stated in a workshop, a report of which will made made publicly available by DHS, just as they did for the first workshop. Sorry you were not present to hear this for yourself, Nico. Steve From kent at bbn.com Thu Jun 2 11:30:45 2005 From: kent at bbn.com (Stephen Kent) Date: Thu, 2 Jun 2005 14:30:45 -0400 Subject: [anonsec] next task, applicability statement In-Reply-To: <429F3556.2010301@isi.edu> References: <20050511220423.GN22993@binky.Central.Sun.COM> <20050512173814.GY22993@binky.Central.Sun.COM> <87e75ea679bf554da3aef66eee4533cc@nomadiclab.com> <429CECC5.4060107@isi.edu> <429E184C.6010800@isi.edu> <429F3556.2010301@isi.edu> Message-ID: Joe, >... > > >> yes, and there are good economic reasons that they are not on line cards. > >Agreed, but when ISPs need the protection, there will be economic >reasons to include them, eventually. Just as forwarding moved onto line >cards, though not economical at first. >... > >I'm arguing that line cards are the input of packets - whether forwarded >or not, and that security triage needs to occur as early as possible. >That is irrespective of whether the packets are ultimately forwarded >(RFC3884) or terminated (e-BGP). forwarding is the primary function of routers, so working to make it more efficient is an obvious router design goal. most folks believe that hop-by-hop protection of subscriber traffic is something a router should NOT do, so putting IPsec on line cards to provide this service is not an obvious design goal a router vendor. >... > > >> As you'll see in my response to your other message, it is not at all >> clear that weakened variants of IPsec represent a good solution here. > >What you described elsewhere are weakend variants of IPsec that just >don't use the IPsec header structure. Do we really need another >structure just for this purpose? No, Joe, not even close. I suggest you re-read what I wrote. It is not at all IPsec-like, since it does not offer integrity or content authentication in MITM contexts, and it emphasizes rate limiting of traffic, a feature not present in IPsec. > > > > My objection was valid then, and it is more relevant now because the >> primary rationale you cited for why IPsec is the right protocol for >> BTNS turns out to be a questionable assertion. > >I believe there are many things to fix with IPsec, and that BTNS and >FASTsec need to both be developed. I further believe that this addresses >the concerns of the ISPs you cited. I'm not sure how many share these beliefs :-) >Sure, killing off half of that effort makes the use of IPsec to solve >e-BGP failures open to DOS attacks, but so does ANY use of high-effort >algorithmic security at any level. no, I explained why your assertion is false in my previous message. >By this argument, ANY use of IPsec >with the current algorithms is doomed, and thus there's no reason to >avoid using IPsec for BTNS, since IPsec itself need not be considered >"holy". IPsec is not "holy," but it does represent the work of a lot of people over many years. It yielded standards that gave rise to a VPN industry and to a protocol that, with varying degrees of fidelity, is implemented in all mainstream operating systems, firewalls, etc. If the justification for creating BTNS is to address unmet security requirements, then BTNS should be free to satisfy these requirements using any protocol that meets the agreed-upon requirements. In that case it is very important that the requirements be validated. If, on the other hand, BTNS was created so that people could revise IPsec, unencumbered by the need to achieve consensus with the membership of the IPsec WG, then there may be less need to validate the requirements used to justify choices made by BTNS. Steve From kent at bbn.com Thu Jun 2 11:20:34 2005 From: kent at bbn.com (Stephen Kent) Date: Thu, 2 Jun 2005 14:20:34 -0400 Subject: [anonsec] next task, applicability statement In-Reply-To: <429F329E.6030102@isi.edu> 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> Message-ID: 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. > > 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. >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. > > 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. >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. >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. > >>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. > >>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. 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. Steve From Nicolas.Williams at sun.com Thu Jun 2 11:56:45 2005 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Thu, 2 Jun 2005 13:56:45 -0500 Subject: [anonsec] next task, applicability statement In-Reply-To: References: <87e75ea679bf554da3aef66eee4533cc@nomadiclab.com> <429CECC5.4060107@isi.edu> <429E184C.6010800@isi.edu> <429F3556.2010301@isi.edu> <20050602172655.GA27456@binky.Central.Sun.COM> Message-ID: <20050602185645.GK27456@binky.Central.Sun.COM> On Thu, Jun 02, 2005 at 01:53:01PM -0400, Stephen Kent wrote: > At 12:26 PM -0500 6/2/05, Nicolas Williams wrote: > >On Thu, Jun 02, 2005 at 09:35:34AM -0700, Joe Touch wrote: > >> Stephen Kent wrote: > >> > At 1:19 PM -0700 6/1/05, Joe Touch wrote: > >> >>Cisco makes modules that, while not on line cards themselves, are > >> >>implemented in hardware (IPsec Services Modules). > >> > > >> > yes, and there are good economic reasons that they are not on line cards. > >> > >> Agreed, but when ISPs need the protection, there will be economic > >> reasons to include them, eventually. Just as forwarding moved onto line > >> cards, though not economical at first. > > > >BTNS has several target consumers/uses as identified at the BoFs. > > > >Stephen claims some of these don't want BTNS today, but that seems > >hardly settled, nor is there reason yet to think that they won't want > >BTNS later. I see no reason yet not to proceed with an applicability > >statement that mentions the use of BTNS by routers to protect BGP TCP > >sessions against off-path attacks against TCP (and therefore BGP). > > > >Nico > > The use of the term "claim" here is pejorative, suggesting that I may > be misrepresenting the facts. [...] I did not have this meaning in mind, I was trying to be concise but failed to be precise. I do trust your report, I just don't think it adds up, yet, to sufficient evidence to discount Joe's use case for BTNS (that proposition, not your report, is what I find hardly settled). Nico -- From touch at ISI.EDU Thu Jun 2 12:14:30 2005 From: touch at ISI.EDU (Joe Touch) Date: Thu, 02 Jun 2005 12:14:30 -0700 Subject: [anonsec] next task, applicability statement In-Reply-To: References: <20050511220423.GN22993@binky.Central.Sun.COM> <20050512173814.GY22993@binky.Central.Sun.COM> <87e75ea679bf554da3aef66eee4533cc@nomadiclab.com> <429CECC5.4060107@isi.edu> <429E184C.6010800@isi.edu> <429F3556.2010301@isi.edu> Message-ID: <429F5A96.7050400@isi.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Stephen Kent wrote: > Joe, > > >>... >> > >> >>> yes, and there are good economic reasons that they are not on line cards. >> >>Agreed, but when ISPs need the protection, there will be economic >>reasons to include them, eventually. Just as forwarding moved onto line >>cards, though not economical at first. >>... >> >>I'm arguing that line cards are the input of packets - whether forwarded >>or not, and that security triage needs to occur as early as possible. >>That is irrespective of whether the packets are ultimately forwarded >>(RFC3884) or terminated (e-BGP). > > forwarding is the primary function of routers, so working to make it > more efficient is an obvious router design goal. most folks believe > that hop-by-hop protection of subscriber traffic is something a > router should NOT do, so putting IPsec on line cards to provide this > service is not an obvious design goal a router vendor. It's something firewalls do, and routers aren't substantially different from firewalls these days in what they need to perform. ...>>> As you'll see in my response to your other message, it is not at all >>> clear that weakened variants of IPsec represent a good solution here. >> >>What you described elsewhere are weakend variants of IPsec that just >>don't use the IPsec header structure. Do we really need another >>structure just for this purpose? > > No, Joe, not even close. I suggest you re-read what I wrote. It is > not at all IPsec-like, since it does not offer integrity or content > authentication in MITM contexts, and it emphasizes rate limiting of > traffic, a feature not present in IPsec. It isn't IPsec/3DES or IPsec/MD5-like, but it can be implemented using IPsec headers inside the IPsec architecture. IPsec may require certain algorithms, but there's no reason not to add others. >> > My objection was valid then, and it is more relevant now because the >> >>> primary rationale you cited for why IPsec is the right protocol for >>> BTNS turns out to be a questionable assertion. >> >>I believe there are many things to fix with IPsec, and that BTNS and >>FASTsec need to both be developed. I further believe that this addresses >>the concerns of the ISPs you cited. > > I'm not sure how many share these beliefs :-) You brought up the ISPs, not me. The feedback you got from them implies that they think that IPsec has this weakness. >>Sure, killing off half of that effort makes the use of IPsec to solve >>e-BGP failures open to DOS attacks, but so does ANY use of high-effort >>algorithmic security at any level. > > no, I explained why your assertion is false in my previous message. I disagree, but see that message (shortly) for why. >>By this argument, ANY use of IPsec >>with the current algorithms is doomed, and thus there's no reason to >>avoid using IPsec for BTNS, since IPsec itself need not be considered >>"holy". > > IPsec is not "holy," but it does represent the work of a lot of > people over many years. It yielded standards that gave rise to a VPN > industry and to a protocol that, with varying degrees of fidelity, is > implemented in all mainstream operating systems, firewalls, etc.\ And isn't being used by ISPs to protect TCP connections for BGP. > If the justification for creating BTNS is to address unmet security > requirements, then BTNS should be free to satisfy these requirements > using any protocol that meets the agreed-upon requirements. In that > case it is very important that the requirements be validated. > > If, on the other hand, BTNS was created so that people could revise > IPsec, unencumbered by the need to achieve consensus with the > membership of the IPsec WG, then there may be less need to validate > the requirements used to justify choices made by BTNS. ANONsec was created to satisfy the requirements using any protocol; BTNS is (IMO) an application of ANONsec to IPsec, because it is provides a useful framework to develop these issues. We already understand that you disagree as to how useful it is, or whether there is implicit damage to the Holy IPsec as a result. But that's not been seen by others here as a reason to avoid proceeding. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCn1qWE5f5cImnZrsRAnXqAJ0StWTl5FNfTaguUfIHPQCm1evkGQCgnCCs COltSGYFbkbjf0mMbCRvXAk= =Nzdq -----END PGP SIGNATURE----- From touch at ISI.EDU Thu Jun 2 12:18:18 2005 From: touch at ISI.EDU (Joe Touch) Date: Thu, 02 Jun 2005 12:18:18 -0700 Subject: [anonsec] next task, applicability statement In-Reply-To: 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> Message-ID: <429F5B7A.5080700@isi.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCn1t6E5f5cImnZrsRAo/6AKDdtESlMazX1uli/MsRv1pUp9isjgCgmv6R vk938DzV57rPaubdOnKt7SE= =QoOZ -----END PGP SIGNATURE----- From kent at bbn.com Thu Jun 2 14:31:30 2005 From: kent at bbn.com (Stephen Kent) Date: Thu, 2 Jun 2005 17:31:30 -0400 Subject: [anonsec] next task, applicability statement In-Reply-To: <429F5A96.7050400@isi.edu> References: <20050511220423.GN22993@binky.Central.Sun.COM> <20050512173814.GY22993@binky.Central.Sun.COM> <87e75ea679bf554da3aef66eee4533cc@nomadiclab.com> <429CECC5.4060107@isi.edu> <429E184C.6010800@isi.edu> <429F3556.2010301@isi.edu> <429F5A96.7050400@isi.edu> Message-ID: Joe, > >forwarding is the primary function of routers, so working to make it > > more efficient is an obvious router design goal. most folks believe >> that hop-by-hop protection of subscriber traffic is something a >> router should NOT do, so putting IPsec on line cards to provide this >> service is not an obvious design goal a router vendor. > >It's something firewalls do, and routers aren't substantially different >from firewalls these days in what they need to perform. Many firewalls have two interfaces, whereas most routers have more interfaces and hence more line cards. Firewalls are placed at well-defined security perimeters, by definition, whereas routers appear at many points in a network. There are a lot of differences that call into question the utility of your firewall/router analogy, with regard to this issue. > >...>>> As you'll see in my response to your other message, it is not at all >>>> clear that weakened variants of IPsec represent a good solution here. >>> >>>What you described elsewhere are weakend variants of IPsec that just >>>don't use the IPsec header structure. Do we really need another >>>structure just for this purpose? >> >> No, Joe, not even close. I suggest you re-read what I wrote. It is >> not at all IPsec-like, since it does not offer integrity or content >> authentication in MITM contexts, and it emphasizes rate limiting of >> traffic, a feature not present in IPsec. > >It isn't IPsec/3DES or IPsec/MD5-like, but it can be implemented using >IPsec headers inside the IPsec architecture. IPsec may require certain >algorithms, but there's no reason not to add others. The purpose of the ICV in ESP or AH is to provide an integrity check for the covered payload, which is substantially different from the rate limitation feature I described. Changing the algorithm used here is not a good way to achieve a fundamentally different security function. > >>> > My objection was valid then, and it is more relevant now because the >>> >>>> primary rationale you cited for why IPsec is the right protocol for >>>> BTNS turns out to be a questionable assertion. >>> >>>I believe there are many things to fix with IPsec, and that BTNS and >>>FASTsec need to both be developed. I further believe that this addresses >>>the concerns of the ISPs you cited. >> >> I'm not sure how many share these beliefs :-) > >You brought up the ISPs, not me. The feedback you got from them implies >that they think that IPsec has this weakness. ISPs are the folks who explained why they did not use MD5, and why they would not use IPsec in this context. It is not a weakness of IPsec, anymore than one would call a screwdriver weak when used as a cold chisel. It is a matter of using an appropriate mechanism in a given context. > >>By this argument, ANY use of IPsec >>>with the current algorithms is doomed, and thus there's no reason to >>>avoid using IPsec for BTNS, since IPsec itself need not be considered >>>"holy". >> >> IPsec is not "holy," but it does represent the work of a lot of >> people over many years. It yielded standards that gave rise to a VPN >> industry and to a protocol that, with varying degrees of fidelity, is >> implemented in all mainstream operating systems, firewalls, etc.\ > >And isn't being used by ISPs to protect TCP connections for BGP. That statement, while true, is misleading, because no ISP can use IPsec for this purpose, since it is not offered for this purpose by router vendors. ISPs don't write code for routers. They configure what Cisco, Juniper, Avica, etc. offer. So, the first hurdle is for the router vendors to offer IPsec as an alternative to MD5 for BGP session protection. Then we can see if ISPs enable it. Given the concerns cited by ISPs re use of MD5, it is not clear that router vendors are scrambling to make IPsec available for this purpose, although that might change if we can address the DoS concern. > >> If the justification for creating BTNS is to address unmet security > > requirements, then BTNS should be free to satisfy these requirements >> using any protocol that meets the agreed-upon requirements. In that >> case it is very important that the requirements be validated. >> >> If, on the other hand, BTNS was created so that people could revise >> IPsec, unencumbered by the need to achieve consensus with the >> membership of the IPsec WG, then there may be less need to validate >> the requirements used to justify choices made by BTNS. > >ANONsec was created to satisfy the requirements using any protocol; BTNS >is (IMO) an application of ANONsec to IPsec, because it is provides a >useful framework to develop these issues. ANONsec doesn't exist, except as a legacy mailing list name. BTNS is the WG that was approved. Thus discussion about the former seems irrelevant. >We already understand that you disagree as to how useful it is, or >whether there is implicit damage to the Holy IPsec as a result. But >that's not been seen by others here as a reason to avoid proceeding. "We?" Is this the same "we" that does not agree with your rationale for a crypto-lite version of IPsec, or the "we" that disagrees with my suggestion that cited rationales for pursuing a course of action in a WG should be re-evaluated when they appear to be false? Steve From kent at bbn.com Thu Jun 2 14:27:13 2005 From: kent at bbn.com (Stephen Kent) Date: Thu, 2 Jun 2005 17:27:13 -0400 Subject: [anonsec] next task, applicability statement In-Reply-To: <429F5B7A.5080700@isi.edu> 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> Message-ID: Joe, >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. In the security business, details are what make systems secure or not, so those of us who do this professionally pay attention to details. > > 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. IKE embodies mechanisms that would allow it to rate limit new IKE SAs, even though such functionality is not specified. Such limiting could be done even in the face of MITM attacks, but it's viability depends on the context in which IKE is used. For router management traffic this would be fairly easy. I'd explain the details, but you've said that such details are not of interest ... >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. In the context we're discussing, router management traffic, the number of peers is not typically large, so the example you cite is not appropriate. > >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. yes, I think we all know MITM is on-path. The model you propose is a MITM who conveniently is asleep when the key exchange takes place, so that the unauthenticated exchange is secure enough. > >>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. that's a very poor solution, because it trades off integrity for management traffic in order to avoid the DoS problem. Using a separate mechanism for rate limiting allows one to use good quality algorithms for integrity while avoiding the DoS concern. >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. What's the "this" you allude to here? >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. sorry you don't see the difference, still. >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.). yes, you could define additional protocols to augment AH and ESP, or different algorithms, or both. the question is whether this is the right way to address the specific problem that you choose to cite as a justification for BTNS. >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. Not quite true. If one implemented a rate limiting mechanism at the IP layer it could be independent of the use of IPsec. it would precede IPsec checking, if present, but it need not supercede it. > > 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. no ISP sent the message, you did. > > 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. the discussion we're having does not convince me that "we all know ..." You keep citing encryption algorithms (e.g., DES), in the context of what you consider an integrity requirement, while I point out that an integrity-less mechanism will suffice. Steve From touch at ISI.EDU Thu Jun 2 15:06:32 2005 From: touch at ISI.EDU (Joe Touch) Date: Thu, 02 Jun 2005 15:06:32 -0700 Subject: [anonsec] next task, applicability statement In-Reply-To: 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> Message-ID: <429F82E8.2010600@isi.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Stephen Kent wrote: >>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. > > In the context we're discussing, router management traffic, the > number of peers is not typically large, so the example you cite is > not appropriate. You already said that there is IKE rate limiting, so it isn't relevant either. >> >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. > > yes, I think we all know MITM is on-path. The model you propose is a > MITM who conveniently is asleep when the key exchange takes place, so > that the unauthenticated exchange is secure enough. MITM attacks during key exchange require either precise timing or interception capability (not just snooping and injection in the latter case). Either case is substantially more challenging attacks than just on-path injection based on snooping. >> >>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. > > that's a very poor solution, because it trades off integrity for > management traffic in order to avoid the DoS problem. Using a > separate mechanism for rate limiting allows one to use good quality > algorithms for integrity while avoiding the DoS concern. I don't want to use JUST watered-IPsec; I want to use multiple layers of IPsec. And rate-limiting, as I noted elsewhere, must occur before the more CPU-intensive versions of IPsec if it is to counter IPsec DOS traffic. As I said, that requires either an IP security protocol outside IPsec to protect via rate limiting, or the use of watered-IPsec outside the regular IPsec. The former unnecessarily requires another IP security 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. > > What's the "this" you allude to here? Increasing IPsec performance was raised in San Diego and agreed as not part of BTNS; the use of that performance enhancement to deal with DOS attacks was part of the current thread. >>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. > > sorry you don't see the difference, still. I believe it is you who does not see the similarity, still. ;-) >>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.). > > yes, you could define additional protocols to augment AH and ESP, or > different algorithms, or both. the question is whether this is the > right way to address the specific problem that you choose to cite as > a justification for BTNS. BTNS isn't designed to solve a specific problem other than the need for pre-agreed keys (preshared or CA certs) to use IPsec. I explained that I considered fixing this key issue a part of how to make IPsec useful to e-BGP, but it isn't sufficient under DOS attacks - nor is IPsec in general. That requires a different solution, but that's not the point of BTNS. I cited e-BGP as one place to use BTNS; the fact that your informal survey of a set of operators suggest that they want more is an indication that there is more to do, not less. >>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. > > Not quite true. If one implemented a rate limiting mechanism at the > IP layer it could be independent of the use of IPsec. it would > precede IPsec checking, if present, but it need not supercede it. If at the IP layer, it must occur on the outermost IP header - it cannot, e.g., occur on the IP header inside an IPsec'd packet. It supercedes it in that if rate limited, the packet would be dropped. The check of IP rate limiting and IPsec needs to be not only ordered, but short-circuited (which is why I chose supercede rather than just precede, but you have issue with that, so let's skip the semantics debate - we're agreeing on the concept). 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. >> > 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. > > no ISP sent the message, you did. It was you who raised the issue of ISPs and DOS attacks (thus the issue of rate limiting), not I. >> > 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. > > the discussion we're having does not convince me that "we all know > ..." You keep citing encryption algorithms (e.g., DES), in the > context of what you consider an integrity requirement, while I point > out that an integrity-less mechanism will suffice. s/DES/MD5/ and s/3DES/SHA/ It doesn't matter whether it's encryption or integrity - there is a need for a variety of algorithms with a variety of CPU effort to support multi-layered filtering as a rate-limiting mechansim. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCn4LoE5f5cImnZrsRAntoAKD6cqHNuwrFAu8WoU+gnTxgXJ5L1gCg9ZSE Hej17Q5zbYv0h5K/P2IG0uk= =is/t -----END PGP SIGNATURE----- From touch at ISI.EDU Thu Jun 2 15:25:13 2005 From: touch at ISI.EDU (Joe Touch) Date: Thu, 02 Jun 2005 15:25:13 -0700 Subject: [anonsec] next task, applicability statement In-Reply-To: References: <20050511220423.GN22993@binky.Central.Sun.COM> <20050512173814.GY22993@binky.Central.Sun.COM> <87e75ea679bf554da3aef66eee4533cc@nomadiclab.com> <429CECC5.4060107@isi.edu> <429E184C.6010800@isi.edu> <429F3556.2010301@isi.edu> <429F5A96.7050400@isi.edu> Message-ID: <429F8749.6080000@isi.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Stephen Kent wrote: > Joe, > > >> >forwarding is the primary function of routers, so working to make it >> > more efficient is an obvious router design goal. most folks believe >> >>> that hop-by-hop protection of subscriber traffic is something a >>> router should NOT do, so putting IPsec on line cards to provide this >>> service is not an obvious design goal a router vendor. >> >>It's something firewalls do, and routers aren't substantially different > >>from firewalls these days in what they need to perform. > > Many firewalls have two interfaces, And many do not; many are made from routers. > whereas most routers have more > interfaces and hence more line cards. Firewalls are placed at > well-defined security perimeters, by definition, whereas routers > appear at many points in a network. There are a lot of differences > that call into question the utility of your firewall/router analogy, > with regard to this issue. Routers, augmented with additional filtering, are used as firewalls. They are needed especially when there are different levels of 'outside', i.e., different levels of trust. >>...>>> As you'll see in my response to your other message, it is not at all >> >>>>> clear that weakened variants of IPsec represent a good solution here. >>>> >>>>What you described elsewhere are weakend variants of IPsec that just >>>>don't use the IPsec header structure. Do we really need another >>>>structure just for this purpose? >>> >>> No, Joe, not even close. I suggest you re-read what I wrote. It is >>> not at all IPsec-like, since it does not offer integrity or content >>> authentication in MITM contexts, and it emphasizes rate limiting of >>> traffic, a feature not present in IPsec. >> >>It isn't IPsec/3DES or IPsec/MD5-like, but it can be implemented using >>IPsec headers inside the IPsec architecture. IPsec may require certain >>algorithms, but there's no reason not to add others. > > The purpose of the ICV in ESP or AH is to provide an integrity check > for the covered payload, which is substantially different from the > rate limitation feature I described. Changing the algorithm used here > is not a good way to achieve a fundamentally different security > function. A null algorithm provides a kind of cookie feature. That's a fine way to achieve at least one variant. IPsec already provides at least two different security functions (encryption and integrity); why not three? >>>> > My objection was valid then, and it is more relevant now because the >>>> >>>> >>>>> primary rationale you cited for why IPsec is the right protocol for >>>>> BTNS turns out to be a questionable assertion. >>>> >>>>I believe there are many things to fix with IPsec, and that BTNS and >>>>FASTsec need to both be developed. I further believe that this addresses >>>>the concerns of the ISPs you cited. >>> >>> I'm not sure how many share these beliefs :-) >> >>You brought up the ISPs, not me. The feedback you got from them implies >>that they think that IPsec has this weakness. > > ISPs are the folks who explained why they did not use MD5, and why > they would not use IPsec in this context. It is not a weakness of > IPsec, anymore than one would call a screwdriver weak when used as a > cold chisel. It is a matter of using an appropriate mechanism in a > given context. The fact that IPsec doesn't support algorithms that are sufficiently fast to use for multilevel DOS triage is a weakness, just as a fixed screwdriver is weaker than a driver with multiple sized heads. >> >>By this argument, ANY use of IPsec >> >>>>with the current algorithms is doomed, and thus there's no reason to >>>>avoid using IPsec for BTNS, since IPsec itself need not be considered >>>>"holy". >>> >>> IPsec is not "holy," but it does represent the work of a lot of >>> people over many years. It yielded standards that gave rise to a VPN >>> industry and to a protocol that, with varying degrees of fidelity, is >>> implemented in all mainstream operating systems, firewalls, etc.\ >> >>And isn't being used by ISPs to protect TCP connections for BGP. > > That statement, while true, is misleading, because no ISP can use > IPsec for this purpose, since it is not offered for this purpose by > router vendors. ISPs don't write code for routers. They configure > what Cisco, Juniper, Avica, etc. offer. So, the first hurdle is for > the router vendors to offer IPsec as an alternative to MD5 for BGP > session protection. Then we can see if ISPs enable it. Given the > concerns cited by ISPs re use of MD5, it is not clear that router > vendors are scrambling to make IPsec available for this purpose, > although that might change if we can address the DoS concern. Speaking of misleading, are you implying that Ipsec needs to be modified to support BGP protection? The existing IPsec on those routers can already be used to support transport assocations for port 179. It's a matter of configuration, not 'enabling' a capability. >>> If the justification for creating BTNS is to address unmet security >> > requirements, then BTNS should be free to satisfy these requirements >>> using any protocol that meets the agreed-upon requirements. In that >>> case it is very important that the requirements be validated. >>> >>> If, on the other hand, BTNS was created so that people could revise >>> IPsec, unencumbered by the need to achieve consensus with the >>> membership of the IPsec WG, then there may be less need to validate >>> the requirements used to justify choices made by BTNS. >> >>ANONsec was created to satisfy the requirements using any protocol; BTNS >>is (IMO) an application of ANONsec to IPsec, because it is provides a >>useful framework to develop these issues. > > ANONsec doesn't exist, except as a legacy mailing list name. BTNS is > the WG that was approved. Thus discussion about the former seems > irrelevant. In the IETF, anonsec is just a mailing list name, but it doesn't cease to exist as a concept just because a portion of the work is being done under BTNS. The ANONsec I am referring to above is the concept, and I raised it to emphasise the point that BTNS _is_ the IPsec version of the keyless security component of that concept. You brought up the point of 'choosing any protocol' to apply it to, and that's where that point exists, not in BTNS. >>We already understand that you disagree as to how useful it is, or >>whether there is implicit damage to the Holy IPsec as a result. But >>that's not been seen by others here as a reason to avoid proceeding. > > "We?" Is this the same "we" that does not agree with your rationale > for a crypto-lite version of IPsec, or the "we" that disagrees with > my suggestion that cited rationales for pursuing a course of action > in a WG should be re-evaluated when they appear to be false? It is the "we" who disagrees with your assertion that IPsec was chosen solely because of the example rational, and the "we" that disagrees that the lack of DOS support in IPsec is a reason not to fix keyless use of IPsec because of anecdotal reports, even if "we" agree with those reports. It is the "we" that isn't interested in debating whether the Holy IPsec should be protected from BTNS and all other modifications that you do not agree with. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCn4dJE5f5cImnZrsRAmjRAKDpWPdZlQC2JuzQV2X1Nf/KTgJ0PwCg8xRt enMq+Lu8y3/0MTp86/9CAfM= =RUIf -----END PGP SIGNATURE----- From kent at bbn.com Fri Jun 3 07:39:34 2005 From: kent at bbn.com (Stephen Kent) Date: Fri, 3 Jun 2005 10:39:34 -0400 Subject: [anonsec] next task, applicability statement In-Reply-To: <429F82E8.2010600@isi.edu> 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> Message-ID: Joe, This exchange is becoming a waste of our time, and probably an annoyance for the others on this list. I'll respond to only one or your comments, because I think it illustrates the miscommunication that so often characterizes our e-mail exchanges. >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. 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. 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. 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. 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. 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. Steve From kent at bbn.com Fri Jun 3 08:26:40 2005 From: kent at bbn.com (Stephen Kent) Date: Fri, 3 Jun 2005 11:26:40 -0400 Subject: [anonsec] next task, applicability statement In-Reply-To: <429F8749.6080000@isi.edu> References: <20050511220423.GN22993@binky.Central.Sun.COM> <20050512173814.GY22993@binky.Central.Sun.COM> <87e75ea679bf554da3aef66eee4533cc@nomadiclab.com> <429CECC5.4060107@isi.edu> <429E184C.6010800@isi.edu> <429F3556.2010301@isi.edu> <429F5A96.7050400@isi.edu> <429F8749.6080000@isi.edu> Message-ID: Joe, > > > Many firewalls have two interfaces, > >And many do not; many are made from routers. most commercial firewalls are designed for that purpose, not recycle routers. even the Cisco products that emphasize firewall capabilities differ from their products that focus on routing, and that are employed as border routers. > >> whereas most routers have more >> interfaces and hence more line cards. Firewalls are placed at >> well-defined security perimeters, by definition, whereas routers >> appear at many points in a network. There are a lot of differences >> that call into question the utility of your firewall/router analogy, > > with regard to this issue. > >Routers, augmented with additional filtering, are used as firewalls. >They are needed especially when there are different levels of 'outside', >i.e., different levels of trust. As above, you may be viewing this more from an abstract perspective than a real product perspective. > > The purpose of the ICV in ESP or AH is to provide an integrity check >> for the covered payload, which is substantially different from the >> rate limitation feature I described. Changing the algorithm used here >> is not a good way to achieve a fundamentally different security >> function. > >A null algorithm provides a kind of cookie feature. That's a fine way to >achieve at least one variant. Null encryption and authentication algorithms exist in IPsec only because folks did not want to make a change to IKE v1 after we decided to allow for integrity-only ESP. Don't make them into anything more than an embarrassing terminology fix necessitated by an oversight in a protocol format. >IPsec already provides at least two different security functions >(encryption and integrity); why not three? You could add another security service, in a new protocol that offered just this service, and make that protocol a part of IPsec. The question is whether the result is generally useful, especially if it necessitates additional layering of SAs. The alternative, which you did not clearly propose or reject, would be to cerate a new protocol that offered optional rate limiting, optional integrity, and optional confidentiality. A sort of ESP+. is that what you had in mind? It's clearly out of scope for BTNS. >The fact that IPsec doesn't support algorithms that are sufficiently >fast to use for multilevel DOS triage is a weakness, just as a fixed >screwdriver is weaker than a driver with multiple sized heads. By this reasoning, TCP is weak because it does not behave like UDP. >Speaking of misleading, are you implying that Ipsec needs to be modified >to support BGP protection? I cannot imagine what prompts this question, other than as a way to change the subject? Use of IPsec to protect BGP is appropriate only if we address the rate limiting of management traffic problem that plagues routers, and which encompasses more than BGP. >The existing IPsec on those routers can already be used to support >transport assocations for port 179. It's a matter of configuration, not >'enabling' a capability. Representatives from Cisco and Juniper both said that one could not configure IPsec to protect BGP sessions in their routers using current products, when asked by attendees at the first DHS routing security workshop, in mid March. >In the IETF, anonsec is just a mailing list name, but it doesn't cease >to exist as a concept just because a portion of the work is being done >under BTNS. > >The ANONsec I am referring to above is the concept, and I raised it to >emphasise the point that BTNS _is_ the IPsec version of the keyless >security component of that concept. "keyless?" I think you mean unauthenticated. Keys are still going to be out in place via IKE and used by AH or ESP, based on the charter I read. Sloppy use of words that engender unnecessarily lengthy e-mail exchanges. >It is the "we" who disagrees with your assertion that IPsec was chosen >solely because of the example rational, and the "we" that disagrees that >the lack of DOS support in IPsec is a reason not to fix keyless use of >IPsec because of anecdotal reports, even if "we" agree with those reports. again, keyless? the sample rationale was precisely the one case cited as to why IPsec was the right choice. that is distinct from a statement on the part of others to use IPsec as the basis for new functionality, irrespective of the presentation of suitable rationale. >It is the "we" that isn't interested in debating whether the Holy IPsec >should be protected from BTNS and all other modifications that you do >not agree with. I guess those of us who have worked on IPsec for many years should be flattered to se it referred to as "Holy." It makes this discussion sound like an argument over an attempt to hijack a well recognized protocol name while changing the underlying functionality. Steve From touch at ISI.EDU Fri Jun 3 09:34:33 2005 From: touch at ISI.EDU (Joe Touch) Date: Fri, 03 Jun 2005 09:34:33 -0700 Subject: [anonsec] next task, applicability statement In-Reply-To: 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> Message-ID: <42A08699.80205@isi.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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 iD8DBQFCoIaZE5f5cImnZrsRArxhAJwLQMZ+2vmwYZhSy7+4enzCZZruRgCeNMZ3 Xs8XPYcEXMdXY+av4tNuE50= =U4RU -----END PGP SIGNATURE----- From touch at ISI.EDU Fri Jun 3 10:02:53 2005 From: touch at ISI.EDU (Joe Touch) Date: Fri, 03 Jun 2005 10:02:53 -0700 Subject: [anonsec] next task, applicability statement In-Reply-To: References: <20050511220423.GN22993@binky.Central.Sun.COM> <20050512173814.GY22993@binky.Central.Sun.COM> <87e75ea679bf554da3aef66eee4533cc@nomadiclab.com> <429CECC5.4060107@isi.edu> <429E184C.6010800@isi.edu> <429F3556.2010301@isi.edu> <429F5A96.7050400@isi.edu> <429F8749.6080000@isi.edu> Message-ID: <42A08D3D.3030403@isi.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Stephen Kent wrote: > Joe, > > >> > Many firewalls have two interfaces, >> >>And many do not; many are made from routers. > > most commercial firewalls are designed for that purpose, not recycle > routers. even the Cisco products that emphasize firewall capabilities > differ from their products that focus on routing, and that are > employed as border routers. Cisco, to pick a data point, makes three kinds of devices: - custom firewalls (5500 series) - firewall module for routers (FWSM) for their 6500 and 7600-series - firewall software for routers I don't know what's faster - 5500 series custom devices or 7600-series routers. I also don't have statistics on what is actually deployed everywhere, but I do know a few universities (which are fairly large) that use predominantly routers, not hardware firewall devices, to do firewalling. >> > The purpose of the ICV in ESP or AH is to provide an integrity check >> >>> for the covered payload, which is substantially different from the >>> rate limitation feature I described. Changing the algorithm used here >>> is not a good way to achieve a fundamentally different security >>> function. >> >>A null algorithm provides a kind of cookie feature. That's a fine way to >>achieve at least one variant. > > Null encryption and authentication algorithms exist in IPsec only > because folks did not want to make a change to IKE v1 after we > decided to allow for integrity-only ESP. Don't make them into > anything more than an embarrassing terminology fix necessitated by an > oversight in a protocol format. A null algoritm (note that I didn't refer to null mode, ala RFC2410) could be used for cookie-based checks, where the SPI and subsequent port checks are what is verified, but no other algorithm is used. >>IPsec already provides at least two different security functions >>(encryption and integrity); why not three? > > You could add another security service, in a new protocol that > offered just this service, and make that protocol a part of IPsec. > The question is whether the result is generally useful, especially if > it necessitates additional layering of SAs. The alternative, which > you did not clearly propose or reject, would be to cerate a new > protocol that offered optional rate limiting, optional integrity, and > optional confidentiality. A sort of ESP+. is that what you had in > mind? It's clearly out of scope for BTNS. There are two security services offered by IPsec - integrity and encryption, differed by the algorithms used. They both are supported in both IPsec protocols - AH and ESP - as well as in IKE. I am proposing other algorithms, closer in spirit to MD5/AES/3DES/SHA than to AH/ESP. I am proposing that although a different protocol could be developed, it would be redundent with IPsec, so I would prefer it to be integrated. Although I had proposed this work as possibly being part of BTNS originally, I appreciate that this is out of scope, and I was not proposing to bring it back. It _is_ a separate effort at ISI, and I welcome others who would be interested in collaborating, and may bring it to the IETF as a different effort when appropriate. >>The fact that IPsec doesn't support algorithms that are sufficiently >>fast to use for multilevel DOS triage is a weakness, just as a fixed >>screwdriver is weaker than a driver with multiple sized heads. > > By this reasoning, TCP is weak because it does not behave like UDP. TCP was weak because it supported congestion control but didn't support window scaling, so we added that. IPsec provides a number of things, including admission control. To the extent that multilevel DOS triage is needed to support efficient admission control, I believe it to be deficient. >>Speaking of misleading, are you implying that Ipsec needs to be modified >>to support BGP protection? > > I cannot imagine what prompts this question, The part where you tell us that routers can't support IPsec on BGP, as per below. ... >>The existing IPsec on those routers can already be used to support >>transport assocations for port 179. It's a matter of configuration, not >>'enabling' a capability. > > Representatives from Cisco and Juniper both said that one could not > configure IPsec to protect BGP sessions in their routers using > current products, when asked by attendees at the first DHS routing > security workshop, in mid March. There must be some adjectives missing, since I have done it with fairly low-end Cisco products. Perhaps IPv6 BGP (IPv6 and IPsec aren't concurrently supported in IOS yet)? >>It is the "we" who disagrees with your assertion that IPsec was chosen >>solely because of the example rational, and the "we" that disagrees that >>the lack of DOS support in IPsec is a reason not to fix keyless use of >>IPsec because of anecdotal reports, even if "we" agree with those reports. > > again, keyless? the sample rationale was precisely the one case cited > as to why IPsec was the right choice. Please review the notes. IPsec is a good choice because: - it protects the transport layer and avoids the need for per-transport protection - IKE and the SPDs are a good framework in which to develop this solution I used BGP as one place the solution might be useful, and I still believe it to be useful there; the concerns about DOS attacks need to be addressed, but affect ALL algorithmic solutions anyway (SSL, TCP/MD5, and IPsec), and only network and transport layer protection will ultimately protect BGP (because of its interpretation of connection interruption). While there are other 'solutions' to off-path attacks, they all fail with respect on-path attacks in ways that BTNS does not (except, as noted, duing the brief window of IKE handshake, or for MITM). As Nico noted, I don't believe we need a single example of overwhelming a-priori willingness to deploy this solution to proceed, however. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCoI09E5f5cImnZrsRAk6jAKD2lUBZLFtp+2NXL1v2cOpLj6h1rACg4kyR vRZxWSZIK3/GIHSsQcWKJuQ= =rCKV -----END PGP SIGNATURE----- From pekka.nikander at nomadiclab.com Sun Jun 5 11:32:31 2005 From: pekka.nikander at nomadiclab.com (Pekka Nikander) Date: Sun, 5 Jun 2005 21:32:31 +0300 Subject: [anonsec] Tagging or rate limiting: please consider another ML and a BOF (was Re: next task, applicability statement) In-Reply-To: <42A08699.80205@isi.edu> 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> Message-ID: <6edf2f56d1b70d6cb1a33ad556e677a9@nomadiclab.com> 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: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > > 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 > > iD8DBQFCoIaZE5f5cImnZrsRArxhAJwLQMZ+2vmwYZhSy7+4enzCZZruRgCeNMZ3 > Xs8XPYcEXMdXY+av4tNuE50= > =U4RU > -----END PGP SIGNATURE----- > _______________________________________________ > From kent at bbn.com Mon Jun 6 07:55:01 2005 From: kent at bbn.com (Stephen Kent) Date: Mon, 6 Jun 2005 10:55:01 -0400 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: Pekka, I'm glad we agree that this is out of scope for BTNS. I disagree that it is an appropriate extension to IPsec, in the form of a new protocol, at least in the router context that motivated the discussion. I will send you the message I was about to send to the list, noting the reasons that this is not such an attractive option. I will not send the message to the list, so as to not perpetuate this exchange. Steve From kent at bbn.com Mon Jun 6 07:56:35 2005 From: kent at bbn.com (Stephen Kent) Date: Mon, 6 Jun 2005 10:56:35 -0400 Subject: [anonsec] response not sent to the list 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: Joe, The short form summary of your message is: - you believe that rate limiting should be effected via weak integrity algorithms and use of sequence numbers, vs. a separate mechanism that decouples integrity from crypto-based rate limiting. you provide no good analysis of why this should be true. - you characterized MD5 as "crackable" in protocols such as ESP & AH, but MD5 is used there in the HMAC construct, so your characterization seems an exaggeration, at best. - you believe routers really should implement IPsec on line cards, even though this is not generally viewed as an appropriate security mechanism for subscriber traffic protection by most folks (except, perhaps, if the router is functioning as an SG for an enterprise), and it is clearly an unduly expensive implementation strategy for protecting router management traffic. - you believe that the AH or ESP format should be reused for rate limiting, which implies a minimum of an 8 byte overhead in addition to the cookie/tag/ICV. this is about double the overhead that would be required for a rate limiting scheme of the sort I suggested. - you appear to believe that devices used as VPN endpoints will be the same as border routers, although product design criteria would suggest otherwise. I could go on, but as I said before, this is probably not a good use of anyone's time. Steve From kent at bbn.com Mon Jun 6 07:59:24 2005 From: kent at bbn.com (Stephen Kent) Date: Mon, 6 Jun 2005 10:59:24 -0400 Subject: [anonsec] other response not sent to the list In-Reply-To: <42A08D3D.3030403@isi.edu> References: <20050511220423.GN22993@binky.Central.Sun.COM> <20050512173814.GY22993@binky.Central.Sun.COM> <87e75ea679bf554da3aef66eee4533cc@nomadiclab.com> <429CECC5.4060107@isi.edu> <429E184C.6010800@isi.edu> <429F3556.2010301@isi.edu> <429F5A96.7050400@isi.edu> <429F8749.6080000@isi.edu> <42A08D3D.3030403@isi.edu> Message-ID: Joe, >... > >> > The purpose of the ICV in ESP or AH is to provide an integrity check >>> >>>> for the covered payload, which is substantially different from the >>>> rate limitation feature I described. Changing the algorithm used here >>>> is not a good way to achieve a fundamentally different security >>>> function. >>> >>>A null algorithm provides a kind of cookie feature. That's a fine way to >>>achieve at least one variant. >> >> Null encryption and authentication algorithms exist in IPsec only >> because folks did not want to make a change to IKE v1 after we >> decided to allow for integrity-only ESP. Don't make them into >> anything more than an embarrassing terminology fix necessitated by an >> oversight in a protocol format. > >A null algoritm (note that I didn't refer to null mode, ala RFC2410) >could be used for cookie-based checks, where the SPI and subsequent port >checks are what is verified, but no other algorithm is used. Reread 2410. It defines an algorithm, not a mode, as per IPsec/IKE terminology. > >>>IPsec already provides at least two different security functions >>>(encryption and integrity); why not three? >> >> You could add another security service, in a new protocol that >> offered just this service, and make that protocol a part of IPsec. >> The question is whether the result is generally useful, especially if >> it necessitates additional layering of SAs. The alternative, which >> you did not clearly propose or reject, would be to cerate a new >> protocol that offered optional rate limiting, optional integrity, and >> optional confidentiality. A sort of ESP+. is that what you had in >> mind? It's clearly out of scope for BTNS. > >There are two security services offered by IPsec - integrity and >encryption, the second service is confidentiality; encryption is the mechanism by which the service is provided. all the IPsec specs are very consistent in this regard. >differed by the algorithms used. the services differ not only in terms of the algorithms employed, but also the data that is protected by them. for example, the SPI and sequence number are almost always integrity protected, and never encrypted. > They both are supported in >both IPsec protocols - AH and ESP - as well as in IKE. No, AH does not offer confidentiality or employ encryption. > I am proposing >other algorithms, closer in spirit to MD5/AES/3DES/SHA than to AH/ESP. AH and ESP are protocols, not algorithms. >I am proposing that although a different protocol could be developed, it >would be redundent with IPsec, so I would prefer it to be integrated. the text above confuses security services with mechanisms, includes misstatements about which services are offered by which protocols, confuses IPsec modes vs. algorithms and algorithm modes, and protocols vs. algorithms. so it's hard for me to know what you really mean when you refer to a different protocol in the sentence immediately above. >TCP was weak because it supported congestion control but didn't support >window scaling, so we added that. > >IPsec provides a number of things, including admission control. nowhere does this term appear in the IPsec specs. do you mean access control? >... > >There must be some adjectives missing, since I have done it with fairly >low-end Cisco products. Perhaps IPv6 BGP (IPv6 and IPsec aren't >concurrently supported in IOS yet)? The response was not related to IPv6.. Are you saying that you have Cisco routers that run BGP and that you have configured them to protect BGP sessions with IPsec as offered internally by the routers? You say that IOS does not support IPsec, but that, presumably, is where IPsec would have to be supported to allow it to be used to protect a BGP session terminating at the management processor in a router of suitable size for use as a border router. Steve From touch at ISI.EDU Mon Jun 6 08:22:03 2005 From: touch at ISI.EDU (Joe Touch) Date: Mon, 06 Jun 2005 08:22:03 -0700 Subject: [anonsec] response not sent to the list In-Reply-To: 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: <42A46A1B.7090603@isi.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Stephen Kent wrote: > Joe, > > The short form summary of your message is: Corrected as below: > - you believe that rate limiting should be effected via weak > integrity algorithms and use of sequence numbers, vs. a separate > mechanism that decouples integrity from crypto-based rate limiting. you > provide no good analysis of why this should be true As you provide none that this is not. > - you characterized MD5 as "crackable" in protocols such as ESP & > AH, but MD5 is used there in the HMAC construct, so your > characterization seems an exaggeration, at best The reports of crackability of MD5 are well-known; it was an illustrative example that some algorithms are stronger than others. > - you believe routers really should implement IPsec on line cards, > even though this is not generally viewed as an appropriate security > mechanism for subscriber traffic protection by most folks (except, > perhaps, if the router is functioning as an SG for an enterprise), and > it is clearly an unduly expensive implementation strategy for protecting > router management traffic. I believe that routing devices - including firewalls - should implement IPsec on line cards for VPNs, as a SG. Protection of router management traffic requires that the management processor can filter whathever traffic is directed to it at whatever rates it can enter the device. That means pushing filtering checks out to the edges - on the line cards - regardless of whether it's IPsec or another algorithm. > - you believe that the AH or ESP format should be reused for rate > limiting, which implies a minimum of an 8 byte overhead in addition to > the cookie/tag/ICV. this is about double the overhead that would be > required for a rate limiting scheme of the sort I suggested. I believe that AH and ESP are already used for rate limiting - to two rates. I further believe that 8 bytes of overhead is negligible; we use 20 for tunnels all over the place without significant concern. > - you appear to believe that devices used as VPN endpoints will be > the same as border routers, although product design criteria would > suggest otherwise. I cited specific products that support this capability, offered by Cisco, and two examples of large university enterprises that provide firewalling using those routers. I agree that this is out of scope for BTNS. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCpGoaE5f5cImnZrsRAtiGAKCYtrIKBXSaAfNBWAR2XedrxxEfBQCfRAUE f8tQo+oOw1ySuPlfWptvJKM= =QDn8 -----END PGP SIGNATURE----- From touch at ISI.EDU Mon Jun 6 08:37:22 2005 From: touch at ISI.EDU (Joe Touch) Date: Mon, 06 Jun 2005 08:37:22 -0700 Subject: [anonsec] other response not sent to the list In-Reply-To: References: <20050511220423.GN22993@binky.Central.Sun.COM> <20050512173814.GY22993@binky.Central.Sun.COM> <87e75ea679bf554da3aef66eee4533cc@nomadiclab.com> <429CECC5.4060107@isi.edu> <429E184C.6010800@isi.edu> <429F3556.2010301@isi.edu> <429F5A96.7050400@isi.edu> <429F8749.6080000@isi.edu> <42A08D3D.3030403@isi.edu> Message-ID: <42A46DB2.20208@isi.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Stephen Kent wrote: > Joe, > >> ... >> >> > The purpose of the ICV in ESP or AH is to provide an integrity >> check >> >>>> >>>>> for the covered payload, which is substantially different from the >>>>> rate limitation feature I described. Changing the algorithm used here >>>>> is not a good way to achieve a fundamentally different security >>>>> function. >>>> >>>> >>>> A null algorithm provides a kind of cookie feature. That's a fine >>>> way to >>>> achieve at least one variant. >>> >>> >>> Null encryption and authentication algorithms exist in IPsec only >>> because folks did not want to make a change to IKE v1 after we >>> decided to allow for integrity-only ESP. Don't make them into >>> anything more than an embarrassing terminology fix necessitated by an >>> oversight in a protocol format. >> >> >> A null algoritm (note that I didn't refer to null mode, ala RFC2410) >> could be used for cookie-based checks, where the SPI and subsequent port >> checks are what is verified, but no other algorithm is used. > > Reread 2410. It defines an algorithm, not a mode, as per IPsec/IKE > terminology. Read my MAIL. I never said RFC2410, whether referring to the mode or the algorithm. >>>> IPsec already provides at least two different security functions >>>> (encryption and integrity); why not three? >>> >>> >>> You could add another security service, in a new protocol that >>> offered just this service, and make that protocol a part of IPsec. >>> The question is whether the result is generally useful, especially if >>> it necessitates additional layering of SAs. The alternative, which >>> you did not clearly propose or reject, would be to cerate a new >>> protocol that offered optional rate limiting, optional integrity, and >>> optional confidentiality. A sort of ESP+. is that what you had in >>> mind? It's clearly out of scope for BTNS. >> >> >> There are two security services offered by IPsec - integrity and >> encryption, > > the second service is confidentiality; encryption is the mechanism by > which the service is provided. all the IPsec specs are very consistent > in this regard. > >> differed by the algorithms used. > > the services differ not only in terms of the algorithms employed, but > also the data that is protected by them. for example, the SPI and > sequence number are almost always integrity protected, and never encrypted. Agreed - but that is not a difference in integrity or confidentiality; that is a difference in how portions of the packet are necessarily protected differently under both variant.s >> They both are supported in >> both IPsec protocols - AH and ESP - as well as in IKE. > > No, AH does not offer confidentiality or employ encryption. But ESP does offer either. >> I am proposing >> other algorithms, closer in spirit to MD5/AES/3DES/SHA than to AH/ESP. > > AH and ESP are protocols, not algorithms. Read the sentence again; that's what I said >> I am proposing that although a different protocol could be developed, it >> would be redundent with IPsec, so I would prefer it to be integrated. > > the text above confuses security services with mechanisms, includes > misstatements about which services are offered by which protocols, > confuses IPsec modes vs. algorithms and algorithm modes, and protocols > vs. algorithms. so it's hard for me to know what you really mean when > you refer to a different protocol in the sentence immediately above. Although different protocols could be developed as alternatives to AH or ESP, in different architectures than IPsec (which itself conruses mechanisms with architectures), there's no need per se. ESP could be used, given different algorithms than MD5/SHA/3DES/AES, to provide filtering for rate limiting. >> TCP was weak because it supported congestion control but didn't support >> window scaling, so we added that. >> >> IPsec provides a number of things, including admission control. > > nowhere does this term appear in the IPsec specs. do you mean access > control? Yes. >> ... >> >> There must be some adjectives missing, since I have done it with fairly >> low-end Cisco products. Perhaps IPv6 BGP (IPv6 and IPsec aren't >> concurrently supported in IOS yet)? > > The response was not related to IPv6.. Are you saying that you have > Cisco routers that run BGP and that you have configured them to protect > BGP sessions with IPsec as offered internally by the routers? You say > that IOS does not support IPsec, IOS does not support IPv6 and IPsec at the same time (it was suggested for performance reasons, encouraging the use of coprocessors rather than just software). IOS does support IPv4 and IPsec, and that can be used to protect BGP ports. > but that, presumably, is where IPsec > would have to be supported to allow it to be used to protect a BGP > session terminating at the management processor in a router of suitable > size for use as a border router. IPsec for large border routers should be supported in hardware, and is via coprocessors. Terminating the IPsec there is fine; once it's in the box, it's in the box. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCpG2yE5f5cImnZrsRAqByAKCoKZYX++wf3OrQ9KPNSB4nRSoINQCeKinH iHdy8uwRRP6D5gF5iezGPKQ= =o6o5 -----END PGP SIGNATURE----- From touch at ISI.EDU Mon Jun 6 09:10:24 2005 From: touch at ISI.EDU (Joe Touch) Date: Mon, 06 Jun 2005 09:10:24 -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: <42A47570.8070502@isi.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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 _______________________________________________ > _______________________________________________ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCpHVwE5f5cImnZrsRAqhgAKD8IVjJ3mNaA7FzTHOmAe+NpOv4/gCfekHH Nhoul6dEp1R2/27C0136qDk= =v9ol -----END PGP SIGNATURE----- From pekka.nikander at nomadiclab.com Mon Jun 6 11:39:13 2005 From: pekka.nikander at nomadiclab.com (Pekka Nikander) Date: Mon, 6 Jun 2005 21:39:13 +0300 Subject: [anonsec] Tagging or rate limiting: please consider another ML and a BOF In-Reply-To: <42A47570.8070502@isi.edu> 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> <42A47570.8070502@isi.edu> Message-ID: <4b1626c7d4ec0e5a562f1e828ff1e226@nomadiclab.com> 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. While I think that some specific points from your discussion should be recorded, such as the potential performance problems related to IPsec processing in routers and especially the potential of DoS against router management processors, many other aspects of the discussions are, according to my judgement, clearly beyond the WG charter. For example, a proposal of early verification/ tagging/cookies of IP packets clearly does not belong to this WG. (But, OTOH, I do think that such tagging may well be a good idea.) Hence, if you want to continue discussing the specific residual threats of using BTNS to (partially) protect router management traffic, that _does_ belong to this list, but if you want to discuss how to solve those residual threats with mechanisms that go beyond anonymous or unauthenticated keying, then that is outside the scope of the WG. >> 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"? Personally, I don't think that the list name matters much. The list charter is probably more important. Personally, I'd like us to focus mostly on the problem first, i.e., the potential DoS that especially on-path but possibly also off-path attackers may pose to the IPsec integrity verification process. The solution could be anything from a partially-redesigned ESP to a new IP extension header or even maybe reuse of some existing fields in some existing headers. But given that, I would suggest something like Tagging IP Packets for Protecting Integrity Protection (TIPPIP) :-) But, as said "triage" as a list name is also fine for me. --Pekka Nikander From Nicolas.Williams at sun.com Mon Jun 6 12:09:54 2005 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Mon, 6 Jun 2005 14:09:54 -0500 Subject: [anonsec] applicability Message-ID: <20050606190954.GV3549@binky.Central.Sun.COM> If we step back from Joe's and Stephen's recent discussion, just what is the applicability of BTNS? Here's something to start with, and let's see what we can build up from there: - BTNS can provide protection against passive attacks. This is weak, but, as the expansion of 'BTNS' says, "better than nothing." - BTNS can help pre-share public keys (and certs). "Connect to somehost, then call me and we'll verify the hashes of each other's public keys." - BTNS can provide IDs suitable as material for channel bindings at higher layers without requiring deployment of an authentication infrastructure for IPsec (no need to pre-share keys, certs; no need for PKI, or Kerberos V). - Anything else? Anyways, whether or not the better-than-nothing protection against passive attacks turns out to be of any practical utility to router administrators, clearly it may yet have uses elsewhere. (The WG charter, BTW, does not even mention routers or BGP.) Ideally the better-than-nothing aspect of BTNS will asymptotically disappear in that we'll all deploy authentication infrastructures or otherwise find suitable ways of exchanging key material :) And if that ideal is at all achievable (and I don't mean to suggest that it is) then BTNS' namesake use is fundamentally a short-term feature, a band-aid. Perhaps this is why I've never felt strongly about Joe's primary BTNS use case and focused instead on the channel bindings aspect of BTNS, or perhaps that's just because that's what I've wanted to have since before that ANONSEC BoF. Be that as it may, I'd like to see some applicability I-D text ;) Cheers, Nico -- From touch at ISI.EDU Mon Jun 6 13:18:42 2005 From: touch at ISI.EDU (Joe Touch) Date: Mon, 06 Jun 2005 13:18:42 -0700 Subject: [anonsec] Tagging or rate limiting: please consider another ML and a BOF In-Reply-To: <4b1626c7d4ec0e5a562f1e828ff1e226@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> <42A47570.8070502@isi.edu> <4b1626c7d4ec0e5a562f1e828ff1e226@nomadiclab.com> Message-ID: <42A4AFA2.6060803@isi.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Pekka Nikander wrote: > 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. > > While I think that some specific points from your discussion > should be recorded, such as the potential performance problems > related to IPsec processing in routers and especially the potential > of DoS against router management processors, many other aspects > of the discussions are, according to my judgement, clearly beyond > the WG charter. For example, a proposal of early verification/ > tagging/cookies of IP packets clearly does not belong to this WG. > (But, OTOH, I do think that such tagging may well be a good idea.) > > Hence, if you want to continue discussing the specific residual > threats of using BTNS to (partially) protect router management > traffic, that _does_ belong to this list, but if you want to discuss > how to solve those residual threats with mechanisms that go beyond > anonymous or unauthenticated keying, then that is outside the scope > of the WG. Sure. Just clarifying. >>>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"? > > Personally, I don't think that the list name matters much. The > list charter is probably more important. Personally, I'd like > us to focus mostly on the problem first, i.e., the potential DoS > that especially on-path but possibly also off-path attackers may > pose to the IPsec integrity verification process. The solution > could be anything from a partially-redesigned ESP to a new > IP extension header or even maybe reuse of some existing fields > in some existing headers. But given that, I would suggest > something like Tagging IP Packets for Protecting Integrity > Protection (TIPPIP) :-) But, as said "triage" as a list name is > also fine for me. I'll setup the list today and announce it later. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCpK+iE5f5cImnZrsRAjNZAJ0WxuXWT5ouBjD4WulRxy9nvQ7pOgCguZsR pvWDaT7HiCl0ytsvuYKo11Y= =yH4w -----END PGP SIGNATURE----- From kent at bbn.com Thu Jun 9 08:26:38 2005 From: kent at bbn.com (Stephen Kent) Date: Thu, 9 Jun 2005 11:26:38 -0400 Subject: [anonsec] applicability In-Reply-To: <20050606190954.GV3549@binky.Central.Sun.COM> References: <20050606190954.GV3549@binky.Central.Sun.COM> Message-ID: At 2:09 PM -0500 6/6/05, Nicolas Williams wrote: >If we step back from Joe's and Stephen's recent discussion, just what is >the applicability of BTNS? good change of topic :-) >Here's something to start with, and let's see what we can build up from >there: > > - BTNS can provide protection against passive attacks. This is weak, > but, as the expansion of 'BTNS' says, "better than nothing." OK > - BTNS can help pre-share public keys (and certs). "Connect to > somehost, then call me and we'll verify the hashes of each other's > public keys." OK, but this implies that we mandate management interfaces that support this capability, not just the changes to the PAD and/or SPD syntax that have been discussed. > - BTNS can provide IDs suitable as material for channel bindings at > higher layers without requiring deployment of an authentication > infrastructure for IPsec (no need to pre-share keys, certs; no need > for PKI, or Kerberos V). this needs more detail to explain the contexts in which this is expected to work, what sort of APIs have have to be created or augmented to support it, etc. (recall that PF_KEY is not a standard, just an informational RFC.) a clear statement of the problem being addressed here is needed. >... > >Ideally the better-than-nothing aspect of BTNS will asymptotically >disappear in that we'll all deploy authentication infrastructures or >otherwise find suitable ways of exchanging key material :) like the temporary wooden buildings constructed at MIT for work on radar, that persisted for about 50 years :-) Steve From Nicolas.Williams at sun.com Thu Jun 9 12:49:04 2005 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Thu, 9 Jun 2005 14:49:04 -0500 Subject: [anonsec] applicability In-Reply-To: References: <20050606190954.GV3549@binky.Central.Sun.COM> Message-ID: <20050609194904.GG659@binky.Central.Sun.COM> On Thu, Jun 09, 2005 at 11:26:38AM -0400, Stephen Kent wrote: > At 2:09 PM -0500 6/6/05, Nicolas Williams wrote: > >If we step back from Joe's and Stephen's recent discussion, just what is > >the applicability of BTNS? > > good change of topic :-) > > >Here's something to start with, and let's see what we can build up from > >there: > > > > - BTNS can provide protection against passive attacks. This is weak, > > but, as the expansion of 'BTNS' says, "better than nothing." > > OK > > > - BTNS can help pre-share public keys (and certs). "Connect to > > somehost, then call me and we'll verify the hashes of each other's > > public keys." > > OK, but this implies that we mandate management interfaces that > support this capability, not just the changes to the PAD and/or SPD > syntax that have been discussed. But this could be optional, and we don't have to get too specific about those interfaces. > > - BTNS can provide IDs suitable as material for channel bindings at > > higher layers without requiring deployment of an authentication > > infrastructure for IPsec (no need to pre-share keys, certs; no need > > for PKI, or Kerberos V). > > this needs more detail to explain the contexts in which this is > expected to work, what sort of APIs have have to be created or > augmented to support it, etc. (recall that PF_KEY is not a standard, > just an informational RFC.) a clear statement of the problem being > addressed here is needed. Yup. That's mentioned in the charter, under item (e). > >... > > > >Ideally the better-than-nothing aspect of BTNS will asymptotically > >disappear in that we'll all deploy authentication infrastructures or > >otherwise find suitable ways of exchanging key material :) > > like the temporary wooden buildings constructed at MIT for work on > radar, that persisted for about 50 years :-) Perhaps :/ Nico -- From kent at bbn.com Thu Jun 9 14:45:10 2005 From: kent at bbn.com (Stephen Kent) Date: Thu, 9 Jun 2005 17:45:10 -0400 Subject: [anonsec] applicability In-Reply-To: <20050609194904.GG659@binky.Central.Sun.COM> References: <20050606190954.GV3549@binky.Central.Sun.COM> <20050609194904.GG659@binky.Central.Sun.COM> Message-ID: Nico, >... > > >> OK, but this implies that we mandate management interfaces that >> support this capability, not just the changes to the PAD and/or SPD >> syntax that have been discussed. > >But this could be optional, and we don't have to get too specific about >those interfaces. If can be optional in the same sense that PAD/SPD changes are optional for those who want to support BTNS functionality. but if we don't define such interfaces then it's not fair to cite this functionality as a context where BTNS is applicable. Steve From Nicolas.Williams at sun.com Thu Jun 9 15:02:15 2005 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Thu, 9 Jun 2005 17:02:15 -0500 Subject: [anonsec] applicability In-Reply-To: References: <20050606190954.GV3549@binky.Central.Sun.COM> <20050609194904.GG659@binky.Central.Sun.COM> Message-ID: <20050609220215.GM659@binky.Central.Sun.COM> On Thu, Jun 09, 2005 at 05:45:10PM -0400, Stephen Kent wrote: > Nico, > > >... > > > > >> OK, but this implies that we mandate management interfaces that > >> support this capability, not just the changes to the PAD and/or SPD > >> syntax that have been discussed. > > > >But this could be optional, and we don't have to get too specific about > >those interfaces. > > If can be optional in the same sense that PAD/SPD changes are > optional for those who want to support BTNS functionality. but if we > don't define such interfaces then it's not fair to cite this > functionality as a context where BTNS is applicable. I used "optional" in response to your use of "mandate" -- I meant to clarify that BTNS implementors wouldn't be required to implement such interfaces if they chose not to implement the optional feature that requires them. Whereas the PAD/SPD changes might well be a fundamental aspect of BTNS and therefore not at all optional for BTNS implementors Must we quibble over the meaning of every sentence we each utter? By now I'm pretty sure we all know what we each mean by "anonymous" or "unauthenticated" on this list, for example, yet it seems that every time someone uses one or the other of those we argue over what they mean. I'd rather get beyond that. Cheers, Nico -- From kent at bbn.com Thu Jun 9 15:32:16 2005 From: kent at bbn.com (Stephen Kent) Date: Thu, 9 Jun 2005 18:32:16 -0400 Subject: [anonsec] private response In-Reply-To: <20050609220215.GM659@binky.Central.Sun.COM> References: <20050606190954.GV3549@binky.Central.Sun.COM> <20050609194904.GG659@binky.Central.Sun.COM> <20050609220215.GM659@binky.Central.Sun.COM> Message-ID: Nico, >On Thu, Jun 09, 2005 at 05:45:10PM -0400, Stephen Kent wrote: >> Nico, >> >> >... >> > > >> >> OK, but this implies that we mandate management interfaces that >> >> support this capability, not just the changes to the PAD and/or SPD >> >> syntax that have been discussed. >> > >> >But this could be optional, and we don't have to get too specific about >> >those interfaces. >> >> If can be optional in the same sense that PAD/SPD changes are >> optional for those who want to support BTNS functionality. but if we >> don't define such interfaces then it's not fair to cite this >> functionality as a context where BTNS is applicable. > >I used "optional" in response to your use of "mandate" -- I meant to >clarify that BTNS implementors wouldn't be required to implement such >interfaces if they chose not to implement the optional feature that >requires them. Whereas the PAD/SPD changes might well be a fundamental >aspect of BTNS and therefore not at all optional for BTNS implementors If you choose to make the PAD/SPD changes a mandatory part of BTNS, but do not require the sort of management interface we were discussing, that's fine. But then you ought not cite an scenario as a supporting application context for BTNS in general, because BTNS in general will not be guaranteed to provide the required support. So, when I said mandate, I meant exactly that. >Must we quibble over the meaning of every sentence we each utter? By >now I'm pretty sure we all know what we each mean by "anonymous" or >"unauthenticated" on this list, for example, yet it seems that every >time someone uses one or the other of those we argue over what they >mean. I'd rather get beyond that. Words are important. If we don't use appropriate terminology, we will argue about this for a long time, we will confuse folks who read the documents and were not part of the WG, etc. As for "anonymous" vs. "unauthenticated" if you review the list traffic, Joe was almost alone in his insistence that the former term was appropriate. Most folks, not just me, argued against his use of the term in this context, according to my tally of the messages. I have spent over 25 years working in the network security area. I am generally considered to be very articulate, both in writing and in speech. Joe, on the other hand, is well known as being very inarticulate, unable to express what may be good ideas, in writing or speech. So, if you want to choose sides on the question of what is or is not a good way to articulate your ideas, characterize the problem being solved, etc. you might want to think twice about who's advice you should take. Steve From Nicolas.Williams at sun.com Thu Jun 9 15:54:35 2005 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Thu, 9 Jun 2005 17:54:35 -0500 Subject: [anonsec] private response In-Reply-To: References: <20050606190954.GV3549@binky.Central.Sun.COM> <20050609194904.GG659@binky.Central.Sun.COM> <20050609220215.GM659@binky.Central.Sun.COM> Message-ID: <20050609225435.GR659@binky.Central.Sun.COM> On Thu, Jun 09, 2005 at 06:32:16PM -0400, Stephen Kent wrote: > Nico, > > >On Thu, Jun 09, 2005 at 05:45:10PM -0400, Stephen Kent wrote: > >> Nico, > >> > >> >... > >> > > > >> >> OK, but this implies that we mandate management interfaces that > >> >> support this capability, not just the changes to the PAD and/or SPD > >> >> syntax that have been discussed. > >> > > >> >But this could be optional, and we don't have to get too specific about > >> >those interfaces. > >> > >> If can be optional in the same sense that PAD/SPD changes are > >> optional for those who want to support BTNS functionality. but if we > >> don't define such interfaces then it's not fair to cite this > >> functionality as a context where BTNS is applicable. > > > >I used "optional" in response to your use of "mandate" -- I meant to > >clarify that BTNS implementors wouldn't be required to implement such > >interfaces if they chose not to implement the optional feature that > >requires them. Whereas the PAD/SPD changes might well be a fundamental > >aspect of BTNS and therefore not at all optional for BTNS implementors > > If you choose to make the PAD/SPD changes a mandatory part of BTNS, > but do not require the sort of management interface we were > discussing, that's fine. But then you ought not cite an scenario as a > supporting application context for BTNS in general, because BTNS in > general will not be guaranteed to provide the required support. So, > when I said mandate, I meant exactly that. You lost the context, which was: > > Nico> - BTNS can help pre-share public keys (and certs). "Connect to > > Nico> somehost, then call me and we'll verify the hashes of each > > Nico> other's > > Nico> public keys." > > > Steve> OK, but this implies that we mandate management interfaces that > Steve> support this capability, not just the changes to the PAD and/or SPD > Steve> syntax that have been discussed. > Nico> But this could be optional, and we don't have to get too specific about Nico> those interfaces. You were commenting on something that had hitherto not been a core part of BTNS. > >Must we quibble over the meaning of every sentence we each utter? By > >now I'm pretty sure we all know what we each mean by "anonymous" or > >"unauthenticated" on this list, for example, yet it seems that every > >time someone uses one or the other of those we argue over what they > >mean. I'd rather get beyond that. > > > Words are important. If we don't use appropriate terminology, we will > argue about this for a long time, we will confuse folks who read the > documents and were not part of the WG, etc. See my other reply to you on this. Nico -- From kent at bbn.com Fri Jun 10 07:38:56 2005 From: kent at bbn.com (Stephen Kent) Date: Fri, 10 Jun 2005 10:38:56 -0400 Subject: [anonsec] apology Message-ID: My recent message, with the subject "private response" was clearly intended to be sent only to Nico, not to the list. None of the security area WG lists in which I participate have employed the CC convention used here, that resulted in this message, and one previous message, being sent to the list. Noneteheless, the error was mine. It was not my intent to share my views on Joe's communication skills with the list. I apologize to Joe for having sent the message to the list. Steve From shep at alum.mit.edu Fri Jun 10 08:26:34 2005 From: shep at alum.mit.edu (Tim Shepard) Date: Fri, 10 Jun 2005 11:26:34 -0400 Subject: [anonsec] the btns WG mailing list (was Re: apology ) In-Reply-To: Your message of Fri, 10 Jun 2005 10:38:56 -0400. Message-ID: Mmmm.... mailing list forwarders that munge the Reply-to: field leaving the From: field un-munged are evil, IMHO. A couple minutes in google can find numerous web pages explaining why. http://www.google.com/search?q=reply-to+harmful Perhaps the btns WG mailing list should be moved to the normal IETF mail servers whose behavior will be more predictable to those of us who are accustomed to other IETF mailing lists? (And the name changed appropriately to avoid using the term "anonymous" which causes more confusion than englightenment in many naive listeners (like me), and must therefore be used only with extreme care which is not entirely possible if the mailing list comes with that word (and a common abbreviation of it) stamped all over the headers of every message.) -Tim Shepard shep at alum.mit.edu From touch at ISI.EDU Fri Jun 10 08:49:48 2005 From: touch at ISI.EDU (Joe Touch) Date: Fri, 10 Jun 2005 08:49:48 -0700 Subject: [anonsec] the btns WG mailing list (was Re: apology ) In-Reply-To: References: Message-ID: <42A9B69C.10708@isi.edu> Tim Shepard wrote: > > Mmmm.... mailing list forwarders that munge the Reply-to: field > leaving the From: field un-munged are evil, IMHO. The list has been changed to reply-to the original poster. The previous configuration of the list is not uncommon, but has been changed at the request of the chairs. As to the name, the list to can renamed and remain at postel.org or moved to ietf.org if the chairs determine the need, but it is also not uncommon for BOF mailing list names not to exactly match the name of the WG they end up becoming, nor for them to be hosted elswhere than ietf.org. Joe -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 254 bytes Desc: OpenPGP digital signature Url : http://www.postel.org/pipermail/anonsec/attachments/20050610/61a3d47c/signature.bin From pekka.nikander at nomadiclab.com Fri Jun 10 08:56:24 2005 From: pekka.nikander at nomadiclab.com (Pekka Nikander) Date: Fri, 10 Jun 2005 11:56:24 -0400 Subject: [anonsec] Anonsec list behaviour changed Message-ID: Folks, In order to avoid annoying future mistakes, the list behaviour has now been changed to *not* to include a Reply-To: header. Consequently, replies go by default to the sender of the message, not to the list. If you want to reply to the list, please make sure to include the list address either in the To: or CC: header, depending on whether you want to primarily answer to the sender of the message and just keep the WG informed about the discussion, or whether you want primarily address the whole WG. Now, let's get back to our chartered items: Jun 05 First version of problem and applicability statement Jul 05 WG LC on problem and applicability statement Jul 05 First version of SPD and/or PAD extensions draft --Pekka From pekka.nikander at nomadiclab.com Fri Jun 10 08:58:04 2005 From: pekka.nikander at nomadiclab.com (Pekka Nikander) Date: Fri, 10 Jun 2005 11:58:04 -0400 Subject: [anonsec] the btns WG mailing list (was Re: apology ) In-Reply-To: <42A9B69C.10708@isi.edu> References: <42A9B69C.10708@isi.edu> Message-ID: Joe (CC: to the list), > As to the name, the list to can renamed and remain at postel.org or > moved to ietf.org if the chairs determine the need, but it is also not > uncommon for BOF mailing list names not to exactly match the name of > the > WG they end up becoming, nor for them to be hosted elswhere than > ietf.org. I think the list name and hosting is fine, but I'd appreciate if you changed the list comment from "Discussion ... security" to something that more clearly refers to the WG. Thanks, --Pekka From touch at ISI.EDU Fri Jun 10 10:54:56 2005 From: touch at ISI.EDU (Joe Touch) Date: Fri, 10 Jun 2005 10:54:56 -0700 Subject: [anonsec] the btns WG mailing list (was Re: apology ) In-Reply-To: References: <42A9B69C.10708@isi.edu> Message-ID: <42A9D3F0.4060900@isi.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Done, both on the mailman pages as well as the postel.org/services.html and postel.org/anonsec sites. Joe Pekka Nikander wrote: > Joe (CC: to the list), > >> As to the name, the list to can renamed and remain at postel.org or >> moved to ietf.org if the chairs determine the need, but it is also not >> uncommon for BOF mailing list names not to exactly match the name of the >> WG they end up becoming, nor for them to be hosted elswhere than >> ietf.org. > > > I think the list name and hosting is fine, but I'd > appreciate if you changed the list comment from > "Discussion ... security" to something that more > clearly refers to the WG. > > Thanks, > > --Pekka -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCqdPwE5f5cImnZrsRAvjcAKCXXPUHYOdefjyb9pJHRBCi3UZE8gCgim0m CIPxJVhe6tKuw/Fp/T8o6OA= =ffqe -----END PGP SIGNATURE----- From kent at bbn.com Mon Jun 13 14:46:49 2005 From: kent at bbn.com (Stephen Kent) Date: Mon, 13 Jun 2005 17:46:49 -0400 Subject: [anonsec] what kind of phase 2 SAs are we negotiating? In-Reply-To: <195562d03735dc684d53d1d022362dd2@nomadiclab.com> References: <20050408173500.GD5837@binky.Central.Sun.COM> <0ca22089ca25525e102aa8716441aa1f@nomadiclab.com> <20050527152246.GH28920@binky.Central.Sun.COM> <20050527152942.GZ1287@binky.Central.Sun.COM> <195562d03735dc684d53d1d022362dd2@nomadiclab.com> Message-ID: At 3:34 PM +0300 6/1/05, Pekka Nikander wrote: > >> On Fri, May 27, 2005 at 12:59:12PM +0300, Pekka Nikander wrote: >>>> Given that we are likely to move to an environment where >>>> the IP addresses are likely to be quite ephemeral, IMHO >>>> there is strong architectural reasons to annotate the >>>> incoming IPsec-protected IP packets with the SA, and even >>>> have back-pointers from the SA to the relevant SPD and PAD >>>> entries. > >> On Fri, May 27, 2005 at 10:22:46AM -0500, Nicolas Williams wrote: >>> I agree, but this won't make the two-nodes-behind-the-same-NAT problem >>> that Michael brings up go away as the PAD entry on the server, in that >>> case, is for the NAT address, not for the address behind the NAT, so >>> we'd have to fix the PAD to be NAT aware. Sigh. > >Hmm. I don't see any immediate reason why an already existing >PAD entry couldn't be "NAT aware" already, but maybe I am missing >something here (and see also below). That is, if you index the >PAD entries by the identity, i.e., the public key or self signed >cert in the BTNS case, couldn't there easily be several PAD entries >with child SAs that have overlapping IP address (ranges)? Sure, >there might be practical difficulties in creating and maintaining >the corresponding SPD entries for outgoing child SA traffic, >especially in the case of BIT* implementations. Especially, packets >that are sent to a new port at the remote IP address are likely >to go to a wrong host or nowhere at all, but that is nothing new >with NATs. That would happen even if you did not use IPsec. In 2401bis, PAD entries are "indexed" by IKE ID. if we use raw keys as IKE IDs, then that fits the current model as well. certs do not seem to be appropriate as an IKE ID form, as they are complex objects with a lot of elements. the PAD specifies how to match an IKE ID against a cert if certs are used. one can easily use the public key from a cert as ID and carry a cert if one believes that this represents a useful way to transfer additional info. If we use keys as IKE IDs only for BTNS, that offers the opportunity to separate the PAD into authenticated entries vs. unauthenticated entries. The advantage is that one might adopt a simple policy of never accepting an assertion about an address for a child SA for an unauthenticated entry, if ANY authenticated entry already has the same address as its ID, or that has an address range for child SAs that covers the address in question. That would make it relatively easy to avoid undermining the existing access controls that rely on the PAD to keep different peers from asserting that they represent the one another's address spaces. In the current PAD design, multiple PAD entries would have overlapping address ranges (for child SAs) only if the local admin (e.g., a user) configured them that way. Such configuration would reflect the local admin's belief that the different peers legitimately represented the same or overlapping address blocks. Steve From pekka.nikander at nomadiclab.com Wed Jun 15 10:16:01 2005 From: pekka.nikander at nomadiclab.com (Pekka Nikander) Date: Wed, 15 Jun 2005 19:16:01 +0200 Subject: [anonsec] what kind of phase 2 SAs are we negotiating? In-Reply-To: References: <20050408173500.GD5837@binky.Central.Sun.COM> <0ca22089ca25525e102aa8716441aa1f@nomadiclab.com> <20050527152246.GH28920@binky.Central.Sun.COM> <20050527152942.GZ1287@binky.Central.Sun.COM> <195562d03735dc684d53d1d022362dd2@nomadiclab.com> Message-ID: <0b868e2dfcd8ae21d590a10c0022efd8@nomadiclab.com> > In 2401bis, PAD entries are "indexed" by IKE ID. if we use raw keys > as IKE IDs, then that fits the current model as well. certs do not > seem to be appropriate as an IKE ID form, as they are complex objects > with a lot of elements. the PAD specifies how to match an IKE ID > against a cert if certs are used. one can easily use the public key > from a cert as ID and carry a cert if one believes that this > represents a useful way to transfer additional info. I like the idea of using public keys as identities a lot. In fact, I've had this preference for quite a long time. :-) > If we use keys as IKE IDs only for BTNS, that offers the opportunity > to separate the PAD into authenticated entries vs. unauthenticated > entries. The advantage is that one might adopt a simple policy of > never accepting an assertion about an address for a child SA for an > unauthenticated entry, if ANY authenticated entry already has the > same address as its ID, or that has an address range for child SAs > that covers the address in question. That would make it relatively > easy to avoid undermining the existing access controls that rely on > the PAD to keep different peers from asserting that they represent > the one another's address spaces. This looks like a good starting point for me. However, I'd appreciate if we could also study how to go further, and create an ability to dynamically build PAD and SPD entries based on "experience". That is, when using BTNS for the first time with a given peer key, the system may have the ability to store the key and prefer that key to keys with no prior experience when opening a connection for the next time. That is not a simple problem, I know, but I also believe that such approach may have long term architectural value. Basically, it may pave way towards an architecture where we are using keys instead of IP addresses as the primary security-meaningful low-level identifiers. (With low-level I mean IP layer and possibly other layers that are clearly "below" the application logic.) > In the current PAD design, multiple PAD entries would have > overlapping address ranges (for child SAs) only if the local admin > (e.g., a user) configured them that way. Such configuration would > reflect the local admin's belief that the different peers > legitimately represented the same or overlapping address blocks. Agreed. --Pekka From kent at bbn.com Wed Jun 15 14:43:43 2005 From: kent at bbn.com (Stephen Kent) Date: Wed, 15 Jun 2005 17:43:43 -0400 Subject: [anonsec] what kind of phase 2 SAs are we negotiating? In-Reply-To: <0b868e2dfcd8ae21d590a10c0022efd8@nomadiclab.com> References: <20050408173500.GD5837@binky.Central.Sun.COM> <0ca22089ca25525e102aa8716441aa1f@nomadiclab.com> <20050527152246.GH28920@binky.Central.Sun.COM> <20050527152942.GZ1287@binky.Central.Sun.COM> <195562d03735dc684d53d1d022362dd2@nomadiclab.com> <0b868e2dfcd8ae21d590a10c0022efd8@nomadiclab.com> Message-ID: Pekka, >... > >I like the idea of using public keys as identities a lot. >In fact, I've had this preference for quite a long time. :-) yes, but in this case we're explicitly dealing with unauthenticated peers, so it makes more sense than in some other cases :-) > >>If we use keys as IKE IDs only for BTNS, that offers the opportunity >>to separate the PAD into authenticated entries vs. unauthenticated >>entries. The advantage is that one might adopt a simple policy of >>never accepting an assertion about an address for a child SA for an >>unauthenticated entry, if ANY authenticated entry already has the >>same address as its ID, or that has an address range for child SAs >>that covers the address in question. That would make it relatively >>easy to avoid undermining the existing access controls that rely on >>the PAD to keep different peers from asserting that they represent >>the one another's address spaces. > >This looks like a good starting point for me. However, I'd >appreciate if we could also study how to go further, and create >an ability to dynamically build PAD and SPD entries based on >"experience". That is, when using BTNS for the first time with >a given peer key, the system may have the ability to store the >key and prefer that key to keys with no prior experience when >opening a connection for the next time. That is not a simple >problem, I know, but I also believe that such approach may have >long term architectural value. Basically, it may pave way towards >an architecture where we are using keys instead of IP addresses >as the primary security-meaningful low-level identifiers. >(With low-level I mean IP layer and possibly other layers >that are clearly "below" the application logic.) I understand your interest in the expanded functionality this would provide, since it is supportive of HIP. But HIP is not the focus of this WG, so a rationale of why this functionality is required to meet BTNS requirements is needed. Steve