From kent at bbn.com Wed May 11 11:34:01 2005 From: kent at bbn.com (Stephen Kent) Date: Wed, 11 May 2005 14:34:01 -0400 Subject: [anonsec] rfc2401bis-06: Why there are no names in SAs? In-Reply-To: References: Message-ID: At 3:57 PM +0300 4/29/05, Pekka Nikander wrote: >[Excuse for cross-posting; followups to ipsec only.] > >Folks, > >While reading rfc2401bis-06 for considering BTNS, I came up >with one serious architectural question. At this point of time >I don't know if this really relates to BTNS or not, but it seems >to have some larger relevance in any case. > >The essence of this question boils down to the nature of IP >addresses. While reading rfc2401bis, it becomes apparent that >it is very much build around the model that the IP addresses >used by different hosts are considered to be stable, or at least >divisible into different security classes in a static manner. >While that may be fine for most if not all current purposes of >IPsec, I am afraid that the Internet in general is moving away >from that notion. The SPD initially supported static IP addresses well, and names only minimally, via ambiguous wording in 2401. This was motivated by the fact that we knew how to deal with addresses well, and we did not have a clear picture how to handle names. >However, in addition to the selectors based on this world view, >the SPD and PAD also have now support for "names", mainly >meant to be used in situations where at least one of the IPsec >devices is an end-host (rather than a security gateway). The >support for these higher-layer, symbolic identifiers seems to >be sufficient for key management and outgoing traffic. What >seems to be especially good is the use of names in linking PAD >and SPD entries together (end of section 4.4.3.4). it is not true that we assume that one end of an SA is a host when names are used in lieu of addresses for both ends. However, it is fair to say that the primary motivation for supporting names was road warriors, even in 2401. 2401 lacked a description of how key management (e.g., IKE) and the SPD were to be linked. This was an oversight, caused by the fact that two different groups of folks worked on each set of documents and there was a rush to get the documents out at the end of the process. In 2401bis we addressed this linkage, motivated in part by the ongoing work in the pki4ipsec WG. The PAD is needed whether we use symbolic names or static IP addresses to identify peers. In either case there has to be a way to express the notion of what set of IDs is a peer authorized to represent. These IDs can be names or IP addresses, depending on how we will match the ID against the SPD. We considered additional uses for names in the PAD, and rejected them due to complexity arguments. For example, an SG might have symbolic names for source addresses for hosts behind it, but then it would have to have a secure way to link the names to the addresses it sees in packets. Given the lack of DNSSEC deployment, DHCP security, etc, we didn't think it was appropriate to mention this sort of functionality. >What seems to be missing is support for incoming traffic. All inbound protected traffic arrives via an SA, and the creation of the SA is the time at which we deal with ID and authorization issues. >More specifically, what I am missing is either > > a) names embedded in (inbound) SAD entries, or The data in an (inbound) SAD entry is used to manage the processing of the arriving packet. Since an IP packet carries addresses, but not names, it does not seem appropriate to put a name in an SAD entry. > b) back pointers from (inbound) SAD entries to > corresponding SPD entries in 2401 we talked about the need to examine the SPD to match received traffic against the selectors associated with an SA. This was one of the most complex aspects of inbound traffic processing, the one that generated the most questions. 2401bis adopted a decorrelated SPD in part to avoid this complexity, and as a result did away with any need to provide a back pointer to the SPD for either inbound or outbound SAD entries. >If either of them were in place, that would allow incoming >packets to be tagged with names. Those names could then, >optionally, be available to apps above. In a host environment this is true, but is is not meaningful for an SG. Might there not be other ways to offer these names to an app? Also, in the absence of an API, it's hard to decide where one might maintain this info, to make it available. >Furthermore, and probably more importantly, tagging >the SAs with names would make it also easier to handle >with potential stale SAs as the SPD is dynamically >changed. In my response to your message about why we do not use SPIs as selectors, I noted that the SPD is not assumed to be dynamic. So, when one starts to talk about dynamic SPD changes, one is moving away from the base IPsec model. One might choose to do this, but the IPsec WG avoided embracing this sort of complexity for many years, so one should be careful when considering such a fundamental change. >Now, is there a specific reason why the (inbound) SAD >entries are not tagged/linked with their corresponding >SPD entries? As noted above, the SAD has no need for such links, now that decorrelation is a fundamental aspect of the processing model. Steve From hartmans-ietf at mit.edu Wed May 11 14:31:43 2005 From: hartmans-ietf at mit.edu (Sam Hartman) Date: Wed, 11 May 2005 17:31:43 -0400 Subject: [anonsec] Milestone to be filled: Decision on whether SPD/PAD extensions are needed In-Reply-To: (Pekka Nikander's message of "Fri, 29 Apr 2005 16:16:29 +0300") References: Message-ID: I think that at a minimum we need a way of saying that a particular SPD entry can be a BTNS entry. I'm not entirely sure what the PAD implications are, but I'm quite certain we need at least a bit in the SPD. From Nicolas.Williams at sun.com Wed May 11 15:04:23 2005 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Wed, 11 May 2005 17:04:23 -0500 Subject: [anonsec] Milestone to be filled: Decision on whether SPD/PAD extensions are needed In-Reply-To: References: Message-ID: <20050511220423.GN22993@binky.Central.Sun.COM> On Wed, May 11, 2005 at 05:31:43PM -0400, Sam Hartman wrote: > I think that at a minimum we need a way of saying that a particular > SPD entry can be a BTNS entry. Why? You should be able to determine this from the address selectors of the SPD entries in conjunction with the PAD. I.e., given an SPD entry you can find matching PAD entry(ies) and determine which peers are BTNS peers that way. In fact, an SPD entry might match all peers, BTNS or otherwise, so marking SPD entries as somehow related to BTNS seems wrong. > I'm not entirely sure what the PAD implications are, but I'm quite > certain we need at least a bit in the SPD. My I-D [1] describes the PAD extensions that I think are necessary. In the BITS case the PAD entries for BTNS peers must associate addresses with BTNS IDs. In the native mode IPsec case we could get away with not having a persistent PAD for BTNS peers as each "socket" or even each datagram read/write event, and therefore the _application_ could deal in BTNS IDs, thus saving the PAD the bother. But even in the native mode IPsec case we may care for persistent PAD entries for some BTNS peers, either made in a leap-of-faith manner or else explicitly by applications (perhaps after performing authentication and channel binding). So, IMO, the PAD needs extending in the BITS and native mode cases, and the SPD does not. [1] http://www.ietf.org/internet-drafts/draft-williams-btns-unauthenticated-bits-00.txt Nico -- From hartmans-ietf at mit.edu Wed May 11 20:28:17 2005 From: hartmans-ietf at mit.edu (Sam Hartman) Date: Wed, 11 May 2005 23:28:17 -0400 Subject: [anonsec] Milestone to be filled: Decision on whether SPD/PAD extensions are needed In-Reply-To: <20050511220423.GN22993@binky.Central.Sun.COM> (Nicolas Williams's message of "Wed, 11 May 2005 17:04:23 -0500") References: <20050511220423.GN22993@binky.Central.Sun.COM> Message-ID: >>>>> "Nicolas" == Nicolas Williams writes: Nicolas> On Wed, May 11, 2005 at 05:31:43PM -0400, Sam Hartman Nicolas> wrote: >> I think that at a minimum we need a way of saying that a >> particular SPD entry can be a BTNS entry. Nicolas> Why? You should be able to determine this from the Nicolas> address selectors of the SPD entries in conjunction with Nicolas> the PAD. I.e., given an SPD entry you can find matching Nicolas> PAD entry(ies) and determine which peers are BTNS peers Nicolas> that way. Because the SPD is designed to specify the system security policy of the system. Specifying whether a particular policy entry requires authentication materially affects the security assumptions for that policy. From Nicolas.Williams at sun.com Thu May 12 09:08:01 2005 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Thu, 12 May 2005 11:08:01 -0500 Subject: [anonsec] Milestone to be filled: Decision on whether SPD/PAD extensions are needed In-Reply-To: References: <20050511220423.GN22993@binky.Central.Sun.COM> Message-ID: <20050512160801.GU22993@binky.Central.Sun.COM> On Wed, May 11, 2005 at 11:28:17PM -0400, Sam Hartman wrote: > >>>>> "Nicolas" == Nicolas Williams writes: > > Nicolas> On Wed, May 11, 2005 at 05:31:43PM -0400, Sam Hartman > Nicolas> wrote: > >> I think that at a minimum we need a way of saying that a > >> particular SPD entry can be a BTNS entry. > > Nicolas> Why? You should be able to determine this from the > Nicolas> address selectors of the SPD entries in conjunction with > Nicolas> the PAD. I.e., given an SPD entry you can find matching > Nicolas> PAD entry(ies) and determine which peers are BTNS peers > Nicolas> that way. > > Because the SPD is designed to specify the system security policy of > the system. Specifying whether a particular policy entry requires > authentication materially affects the security assumptions for that > policy. The 2401bis model relies on the PAD for specifying how authentication is done. The connection between SPD and PAD is the addresses of the packets that match the SPD entries, as the addresses are the key into the PAD. Or, at least, that's how I understand it. Nico -- From kent at bbn.com Thu May 12 10:19:04 2005 From: kent at bbn.com (Stephen Kent) Date: Thu, 12 May 2005 13:19:04 -0400 Subject: [anonsec] Milestone to be filled: Decision on whether SPD/PAD extensions are needed In-Reply-To: <20050511220423.GN22993@binky.Central.Sun.COM> References: <20050511220423.GN22993@binky.Central.Sun.COM> Message-ID: Nicolas, I agree with Sam here. The SPD embodies the description of access control policy, and the PAD is the linkage to key management, so that we have a way to constrain the range of IDs that we are willing to accept from a peer, and then use for lookup of SPD entries. That said, I have not read your I-D to see what you proposed in detail, so maybe I'll come to a different conclusion afterwards :-). Steve From Nicolas.Williams at sun.com Thu May 12 10:38:14 2005 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Thu, 12 May 2005 12:38:14 -0500 Subject: [anonsec] Milestone to be filled: Decision on whether SPD/PAD extensions are needed In-Reply-To: References: <20050511220423.GN22993@binky.Central.Sun.COM> Message-ID: <20050512173814.GY22993@binky.Central.Sun.COM> On Thu, May 12, 2005 at 01:19:04PM -0400, Stephen Kent wrote: > Nicolas, > > I agree with Sam here. The SPD embodies the description of access > control policy, and the PAD is the linkage to key management, so that > we have a way to constrain the range of IDs that we are willing to > accept from a peer, and then use for lookup of SPD entries. I can see now that it could be useful to be able to reference a peer's BTNS or non-BTNS status in the SPD (see below), but I don't see it as absolutely necessary. The PAD, according to 2401bis, describes how to authenticate peers. BTNS peers might be "authenticated" by using public key values as IDs, but that is still, in a way, authentication, and so policies like: "10.100.1/24 use BTNS" or "10.100.1.23 is a BTNS peer using public key ID value XYZ" belon in the PAD. Now, to then allow all BTNS peers only access to, say, DNS, then the SPD can reference those addresses... But I see now that that could get unwieldy! > That said, I have not read your I-D to see what you proposed in > detail, so maybe I'll come to a different conclusion afterwards :-). Please do. I do now think that an SPD extension would indeed be useful. But the PAD extensions described in my I-D are also necessary. Nico -- From hartmans-ietf at mit.edu Thu May 12 10:59:32 2005 From: hartmans-ietf at mit.edu (Sam Hartman) Date: Thu, 12 May 2005 13:59:32 -0400 Subject: [anonsec] Milestone to be filled: Decision on whether SPD/PAD extensions are needed In-Reply-To: <20050512173814.GY22993@binky.Central.Sun.COM> (Nicolas Williams's message of "Thu, 12 May 2005 12:38:14 -0500") References: <20050511220423.GN22993@binky.Central.Sun.COM> <20050512173814.GY22993@binky.Central.Sun.COM> Message-ID: >>>>> "Nicolas" == Nicolas Williams writes: Nicolas> On Thu, May 12, 2005 at 01:19:04PM -0400, Stephen Kent Nicolas> wrote: >> Nicolas, >> >> I agree with Sam here. The SPD embodies the description of >> access control policy, and the PAD is the linkage to key >> management, so that we have a way to constrain the range of IDs >> that we are willing to accept from a peer, and then use for >> lookup of SPD entries. Nicolas> I can see now that it could be useful to be able to Nicolas> reference a peer's BTNS or non-BTNS status in the SPD Nicolas> (see below), but I don't see it as absolutely necessary. It's not absolutely necessary to create an implementation I agree. I think it is necessary to preserve the access control model of IPsec and to keep policy defined in the SPD. From kent at bbn.com Thu May 12 11:18:39 2005 From: kent at bbn.com (Stephen Kent) Date: Thu, 12 May 2005 14:18:39 -0400 Subject: [anonsec] Milestone to be filled: Decision on whether SPD/PAD extensions are needed In-Reply-To: <20050512173814.GY22993@binky.Central.Sun.COM> References: <20050511220423.GN22993@binky.Central.Sun.COM> <20050512173814.GY22993@binky.Central.Sun.COM> Message-ID: At 12:38 PM -0500 5/12/05, Nicolas Williams wrote: >On Thu, May 12, 2005 at 01:19:04PM -0400, Stephen Kent wrote: >> Nicolas, >> >> I agree with Sam here. The SPD embodies the description of access >> control policy, and the PAD is the linkage to key management, so that >> we have a way to constrain the range of IDs that we are willing to >> accept from a peer, and then use for lookup of SPD entries. > >I can see now that it could be useful to be able to reference a peer's >BTNS or non-BTNS status in the SPD (see below), but I don't see it as >absolutely necessary. > >The PAD, according to 2401bis, describes how to authenticate peers. The PAD text in 2401bis says that the PAD does two things: - how to authenticate a peer, which certainly suggests that a PAD extension to represent a peer's status re BTNS will be essential - what type and range of IDs the peer is authorized to represent, which is essential to preventing an authenticated (or unauthenticated) peer from asserting an ID for lookup in the SPD when that peer is not authorized to do so Steve From pekka.nikander at nomadiclab.com Fri May 27 02:59:12 2005 From: pekka.nikander at nomadiclab.com (Pekka Nikander) Date: Fri, 27 May 2005 12:59:12 +0300 Subject: [anonsec] what kind of phase 2 SAs are we negotiating? In-Reply-To: References: <20050408173500.GD5837@binky.Central.Sun.COM> Message-ID: <0ca22089ca25525e102aa8716441aa1f@nomadiclab.com> [Catching up] [Discussion about BTNS and NATs, like the following:] > Let's take the following network: > > A1------------\ > +-NAT----S > B1------------/ [Michael getting to the following conclusion:] > This suggests that the IPsec layer of S must either do NAT itself > before > passing the packets upwards, or must be well enough integrated into > the stack > that it can annotate the PCB with an appropriate SA. 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. Yes, I know that this not really possible with BITS or BITW, but I'm genuinely afraid that much of the current IP-address-relying IPsec practises will break down at some not-too-distant point in the future anyway. --Pekka From Nicolas.Williams at sun.com Fri May 27 08:22:46 2005 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Fri, 27 May 2005 10:22:46 -0500 Subject: [anonsec] what kind of phase 2 SAs are we negotiating? In-Reply-To: <0ca22089ca25525e102aa8716441aa1f@nomadiclab.com> References: <20050408173500.GD5837@binky.Central.Sun.COM> <0ca22089ca25525e102aa8716441aa1f@nomadiclab.com> Message-ID: <20050527152246.GH28920@binky.Central.Sun.COM> On Fri, May 27, 2005 at 12:59:12PM +0300, Pekka Nikander wrote: > [Catching up] > > [Discussion about BTNS and NATs, like the following:] > > > Let's take the following network: > > > > A1------------\ > > +-NAT----S > > B1------------/ > > [Michael getting to the following conclusion:] > > > This suggests that the IPsec layer of S must either do NAT itself > > before > > passing the packets upwards, or must be well enough integrated into > > the stack > > that it can annotate the PCB with an appropriate SA. Note that some implementations already support latching of SA IDs (and other parameters) to PCBs. IIRC KAME has an IP_POLICY socket option for that, and Solaris has IP_SEC_POLICY. This is not news. My first I-D focused on BITS because that was easy, even if seriously unsatisfactory. Next someone should publish an I-D describing the binding done and maintained by IP_POLICY/IP_SEC_POLICY. > 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. 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. > Yes, I know that this not really possible with BITS or BITW, > but I'm genuinely afraid that much of the current > IP-address-relying IPsec practises will break down at > some not-too-distant point in the future anyway. I share your sentiment. Nico -- From Nicolas.Williams at sun.com Fri May 27 08:29:42 2005 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Fri, 27 May 2005 10:29:42 -0500 Subject: [anonsec] what kind of phase 2 SAs are we negotiating? In-Reply-To: <20050527152246.GH28920@binky.Central.Sun.COM> References: <20050408173500.GD5837@binky.Central.Sun.COM> <0ca22089ca25525e102aa8716441aa1f@nomadiclab.com> <20050527152246.GH28920@binky.Central.Sun.COM> Message-ID: <20050527152942.GZ1287@binky.Central.Sun.COM> On Fri, May 27, 2005 at 10:22:46AM -0500, Nicolas Williams 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. > > 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. 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 don't know of any such applications, but, do none such exist? Nico -- From sommerfeld at sun.com Fri May 27 10:59:06 2005 From: sommerfeld at sun.com (Bill Sommerfeld) Date: Fri, 27 May 2005 10:59:06 -0700 Subject: [anonsec] what kind of phase 2 SAs are we negotiating? In-Reply-To: <20050527152246.GH28920@binky.Central.Sun.COM> References: <20050408173500.GD5837@binky.Central.Sun.COM> <0ca22089ca25525e102aa8716441aa1f@nomadiclab.com> <20050527152246.GH28920@binky.Central.Sun.COM> Message-ID: <1117216746.38112.132.camel@unknown.hamachi.org> On Fri, 2005-05-27 at 08:22, Nicolas Williams wrote: > IIRC KAME has an IP_POLICY socket option for > that, and Solaris has IP_SEC_POLICY. This is not news. in case anyone stumbles across this in a mail archive and actually wants to write code based on this: solaris has a socket option named IP_SEC_OPT, not IP_SEC_POLICY, which sets a requested/required algorithm set for AH and/or ESP. % grep IP_SEC /usr/include/netinet/*.h /usr/include/netinet/in.h:#define IP_SEC_OPT 0x22 /* Used to set IPSEC options */ - Bill From pekka.nikander at nomadiclab.com Fri May 27 03:18:43 2005 From: pekka.nikander at nomadiclab.com (Pekka Nikander) Date: Fri, 27 May 2005 13:18:43 +0300 Subject: [anonsec] Consensus call: Decision on whether SPD/PAD extensions are needed In-Reply-To: References: <20050511220423.GN22993@binky.Central.Sun.COM> <20050512173814.GY22993@binky.Central.Sun.COM> Message-ID: <87e75ea679bf554da3aef66eee4533cc@nomadiclab.com> [Chairing] Folks, Having read the discussion about whether SPD/PAD extensions are needed, I'd interpret the WG opinion as follows: - SPD extensions (at least one bit) is needed to retain the IPsec semantics; alternatively, even though it may be possible (at least in some cases) to derive that information from the PAD, storing the information in the SPD would be useful anyway - PAD extensions are clearly needed Given the above, my interpretation is that we do need both SPD and PAD extensions in practise. At this point of time I don't think it matters, in practise, why exactly we need SPD extensions; i.e., whether it is necessary to retain the IPsec semantics or just useful. As such, I consider the WG having reached consensus on this and our first milestone to be fulfilled. If you don't agree with this, please indicate so now, latest on June 3rd. --- Our next milestone is now the first version of the problem and applicability statement. Joe Touch and David Black are working on that, me helping. The plan is to proceed fast with that, and have it WG LCd before Paris. --Pekka From Nicolas.Williams at sun.com Sat May 28 13:38:20 2005 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Sat, 28 May 2005 15:38:20 -0500 Subject: [anonsec] what kind of phase 2 SAs are we negotiating? In-Reply-To: <1117216746.38112.132.camel@unknown.hamachi.org> References: <20050408173500.GD5837@binky.Central.Sun.COM> <0ca22089ca25525e102aa8716441aa1f@nomadiclab.com> <20050527152246.GH28920@binky.Central.Sun.COM> <1117216746.38112.132.camel@unknown.hamachi.org> Message-ID: <20050528203820.GR28920@binky.Central.Sun.COM> On Fri, May 27, 2005 at 10:59:06AM -0700, Bill Sommerfeld wrote: > On Fri, 2005-05-27 at 08:22, Nicolas Williams wrote: > > IIRC KAME has an IP_POLICY socket option for > > that, and Solaris has IP_SEC_POLICY. This is not news. > > in case anyone stumbles across this in a mail archive and actually wants > to write code based on this: > > solaris has a socket option named IP_SEC_OPT, not IP_SEC_POLICY, which > sets a requested/required algorithm set for AH and/or ESP. > > % grep IP_SEC /usr/include/netinet/*.h > /usr/include/netinet/in.h:#define IP_SEC_OPT 0x22 > /* Used to set IPSEC options */ Typo. Thanks. From kent at bbn.com Tue May 31 07:45:37 2005 From: kent at bbn.com (Stephen Kent) Date: Tue, 31 May 2005 10:45:37 -0400 Subject: [anonsec] next task, applicability statement In-Reply-To: <87e75ea679bf554da3aef66eee4533cc@nomadiclab.com> References: <20050511220423.GN22993@binky.Central.Sun.COM> <20050512173814.GY22993@binky.Central.Sun.COM> <87e75ea679bf554da3aef66eee4533cc@nomadiclab.com> Message-ID: Folks, I attended a DHS workshop on routing security in Seattle, May 18-19. A number of ISPs were represented at the workshop, which took place immediately after the NANOG meeting in Seattle. One of the topics discussed was "do you use the TCP/MD5 checksum to secure e-BGP sessions, and if not, why not?" 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. Note that the MD5 processing was not, per se, the fundamental problem, although it contributed to the problem. Rather, any moderate amount of traffic that cannot be filtered by line cards and that appears to be management traffic, will often be sufficient to overwhelm the management processor on a router, thus leading to the DoS concern. MD5 protection for BGP traffic just makes this generic problem worse. One might argue that use of IPsec could ameliorate this problem because an attacker would need to be able to guess the SPI for protected traffic, and if a line card could be configured to look a very limited set of currently valid SPIs, then this traffic could be filtered quickly and efficiently. However, we were advised that even such simple checks as the TTL-255 hack were not implementable on some routers, until ASIC changes are effected. That suggests that filtering on a non-IP header value that charges over time (as opposed to the simple IP header check for a TTL value of 255 o 254 for traffic addressed to the router itself) may not be easy to implement in many deployed routers. 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. Steve From shep at alum.mit.edu Tue May 31 10:08:43 2005 From: shep at alum.mit.edu (Tim Shepard) Date: Tue, 31 May 2005 13:08:43 -0400 Subject: [anonsec] next task, applicability statement In-Reply-To: Your message of Tue, 31 May 2005 10:45:37 -0400. Message-ID: > One might argue that use of IPsec could ameliorate this problem > because an attacker would need to be able to guess the SPI for > protected traffic, and if a line card could be configured to look a > very limited set of currently valid SPIs, then this traffic could be > filtered quickly and efficiently. However, we were advised that even An attacker could also flood you with IKE requests too, so your IKE implementation would also have to be hardened to defend against DOS attacks, particularly to not burn cycles doing modular exponentiation for illegitimate requests. How to sort the legitimate requests from the illegitimate requests is a thorny problem. -Tim Shepard shep at alum.mit.edu From touch at ISI.EDU Tue May 31 16:01:25 2005 From: touch at ISI.EDU (Joe Touch) Date: Tue, 31 May 2005 16:01:25 -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> Message-ID: <429CECC5.4060107@isi.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Stephen Kent wrote: > Folks, > > I attended a DHS workshop on routing security in Seattle, May 18-19. > A number of ISPs were represented at the workshop, which took place > immediately after the NANOG meeting in Seattle. One of the topics > discussed was "do you use the TCP/MD5 checksum to secure e-BGP > sessions, and if not, why not?" > > 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. > > Note that the MD5 processing was not, per se, the fundamental > problem, although it contributed to the problem. Rather, any moderate > amount of traffic that cannot be filtered by line cards and that > appears to be management traffic, will often be sufficient to > overwhelm the management processor on a router, thus leading to the > DoS concern. MD5 protection for BGP traffic just makes this generic > problem worse. > > One might argue that use of IPsec could ameliorate this problem > because an attacker would need to be able to guess the SPI for > protected traffic, and if a line card could be configured to look a > very limited set of currently valid SPIs, then this traffic could be > filtered quickly and efficiently. However, we were advised that even > such simple checks as the TTL-255 hack were not implementable on some > routers, until ASIC changes are effected. That suggests that > filtering on a non-IP header value that charges over time (as opposed > to the simple IP header check for a TTL value of 255 o 254 for > traffic addressed to the router itself) may not be easy to implement > in many deployed routers. > > 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. If IPsec processing cannot be offloaded to line cards and run at rate, then it is doomed as a security mechanism. 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. 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 believe that BTNS is a step in the right direction - relieving key management concerns from IPsec deployment - and will ultimately benefit more than just e-BGP, esp. as it becomes easier to guess address/port pairs either by exhaustion, prediction, or snooping. However, it won't solve all impediments to IPsec deployment, and performance and latency are the other two that remain on my list, whether in the IETF or elsewhere. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCnOzFE5f5cImnZrsRArilAKDjbZB+841Z2bdWjQEzLZCFN1ERNwCgpADT 0hqs2ryvEk7ufZddv00aVGw= =ZmwF -----END PGP SIGNATURE----- From Nicolas.Williams at sun.com Tue May 31 16:11:34 2005 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Tue, 31 May 2005 18:11:34 -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> Message-ID: <20050531231134.GX20324@binky.Central.Sun.COM> 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 -- From touch at ISI.EDU Tue May 31 16:11:26 2005 From: touch at ISI.EDU (Joe Touch) Date: Tue, 31 May 2005 16:11:26 -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> Message-ID: <429CEF1E.80009@isi.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 FWIW, regarding the title of the thread, I am drafting the AS right now, just as a status. PS - It seems like IPsec would help compared to TCP/MD5, as the former is often supported via line card hardware, whereas the latter isn't (or at least that's my impression - can anyone with router hardware experience speak to that?) Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCnO8eE5f5cImnZrsRAjzPAKCeIhWY+Y/jGTFAAmKP8m9GODmHhQCgsan6 wPRT/BwBnR9lKpCSpDkxGdE= =d6I2 -----END PGP SIGNATURE-----