From atkinson@tengwar.itd.nrl.navy.mil Tue Dec 1 06:46:06 1992 Received: from interlock.ans.net by nis.ans.net with SMTP id AA45431 (5.65c/IDA-1.4.4 for ); Tue, 1 Dec 1992 11:38:06 -0500 Received: from tengwar.itd.nrl.navy.mil by interlock.ans.net with SMTP id AA22156 (InterLock SMTP Gateway 1.1 for ); Tue, 1 Dec 1992 11:45:39 -0500 Message-Id: <199212011645.AA22156@interlock.ans.net> Received: by tengwar.itd.nrl.navy.mil (16.8/16.2) id AA07275; Tue, 1 Dec 92 11:46:06 -0500 From: atkinson@tengwar.itd.nrl.navy.mil (Randall Atkinson) Date: Tue, 1 Dec 1992 11:46:06 EST In-Reply-To: Stephen D Crocker "Re: Draft Charter IPSEC WG" (Nov 25, 6:54pm) X-Mailer: Mail User's Shell (7.2.3 5/22/91) To: Stephen D Crocker Subject: Re: Draft Charter IPSEC WG Cc: ipsec@ans.net I tend to agree with Steve that we ought to be able to share the key management mechanisms. Why not setup a parallel WG to work on the key mgmt aspects while the IP Security WG works on the authentication/confidentiality mechanisms for IP ?? Ran atkinson@itd.nrl.navy.mil -- From atkinson@tengwar.itd.nrl.navy.mil Tue Dec 1 08:25:45 1992 Received: from interlock.ans.net by nis.ans.net with SMTP id AA59330 (5.65c/IDA-1.4.4 for ); Tue, 1 Dec 1992 13:18:04 -0500 Received: from tengwar.itd.nrl.navy.mil by interlock.ans.net with SMTP id AA15692 (InterLock SMTP Gateway 1.1 for ); Tue, 1 Dec 1992 13:25:24 -0500 Message-Id: <199212011825.AA15692@interlock.ans.net> Received: by tengwar.itd.nrl.navy.mil (16.8/16.2) id AA07558; Tue, 1 Dec 92 13:25:45 -0500 From: atkinson@tengwar.itd.nrl.navy.mil (Randall Atkinson) Date: Tue, 1 Dec 1992 13:25:45 EST In-Reply-To: kasten@ftp.com (Frank Kastenholz) "Re: Draft Charter IPSEC WG" (Dec 1, 12:48pm) X-Mailer: Mail User's Shell (7.2.3 5/22/91) To: kasten@ftp.com Subject: Re: Network Layer Security Properties Cc: ipsec@ans.net, big-Internet@munnari.oz.au Frank, In my own view, IP/ICMP/etc primarily need to have two properties that are not currently available: authentication (preclude Super Source Quench [1], preclude routing attacks, etc) and data integrity (prevents folks from twiddling other folks bits without the receiver knowing about it). In my view, these two properties need to be available in an ordinary IP/SIP/CLNP/etc option and must not require the use of an encapsulating protocol -- if we want to really provide basic security to the majority of the Internet sites. Every site needs these two properties TODAY to preclude simple obvious attacks on the network and hosts connected to the network. Confidentiality via encryption is not as critical at the network layer, though probably good to have [2]. For confidentiality, use of an encapsulating protocol such as SP3 or the ISO Network Layer Security Protocol (NLSP) sounds reasonable. Because relatively fewer sites are really worried about network layer confidentiality, use of an encapsulating protocol by the interested sites is fine. This is not arguing against an SP3/NLSP basis for the IP Security work. Rather it is suggesting that, while an encapsulating SP3/NLSP-like protocol be developed for use, thought also be given to incorporating compatible authentication/integrity mechanisms in new options to the regular network protocol (IP/SIP/CLNP/whatever). I suspect that not much can really be done with IPv4 because of the current header/options size restriction. Regards, Ran atkinson@itd.nrl.navy.mil [1] ICMP message to the victim host that declares the default gateway address to be 127.0.0.1; similar attacks are also possible. [2] I'm trying to avoid starting a layer war here. Some sites don't believe they ever need confidentiality outside the application layer, and there is little consensus in the community on the question of handling confidentiality at the Transport Layer or the Network Layer. -- From karn@qualcomm.com Tue Dec 1 06:55:49 1992 Received: from interlock.ans.net by nis.ans.net with SMTP id AA45140 (5.65c/IDA-1.4.4 for ); Tue, 1 Dec 1992 17:49:07 -0500 Received: from qualcomm.com (qualcom.qualcomm.com) by interlock.ans.net with SMTP id AA03625 (InterLock SMTP Gateway 1.1 for ); Tue, 1 Dec 1992 17:55:34 -0500 Received: from servo.qualcomm.com by qualcomm.com; id AA02135 sendmail 5.65/QC-main-2.1 via SMTP Tue, 1 Dec 92 14:55:52 -0800 for ipsec@ans.net Received: by servo; id AA26782 sendmail 5.67/QC-subsidiary-2.1 Tue, 1 Dec 92 14:55:49 -0800 for kasten@ftp.com Date: Tue, 1 Dec 92 14:55:49 -0800 From: karn@qualcomm.com (Phil Karn) Message-Id: <9212012255.AA26782@servo> To: atkinson@tengwar.itd.nrl.navy.mil, kasten@ftp.com Subject: Re: Network Layer Security Properties Cc: big-Internet@munnari.oz.au, ipsec@ans.net Ran Atkinson: >In my view, these two properties need to be available in an ordinary >IP/SIP/CLNP/etc option and must not require the use of an encapsulating >protocol -- if we want to really provide basic security to the majority >of the Internet sites. I don't see how this follows. As the core protocol of the Internet, IP's simplicity (so far) is largely responsible for the success of the entire Internet. There's a very real danger of the "second system effect" in the IPv7 project, especially as the frustrated OSIers get involved. (Personally I agree with Noel Chiappa that switching the whole Internet to a new routing and addressing architecture at the same time would be sheer madness. I'd much prefer to find clever, compatible ways to get more out of the 32 bit addresses in IPv4 headers.) So I think it's important to review what I personally consider to be the most important principles of the current IP (IPv4) design that ought to be retained in any new IP -- if in fact there *is* to be a new IP: 1. The protocol is connectionless. (This ought to go without saying, but I guess it doesn't.) 2. The internet protocol contains ONLY those fields that must be there for the routers to do their job. This is true for every field in the IPv4 header with the exception of the Protocol field, which is interpreted by the destination host. 3. There is a "basic" IP header format with fields of fixed size that is sufficiently useful to account for the vast majority of Internet packets. High performance routers can then be heavily optimized around this format, perhaps by building custom hardware. The relatively few packets with options can be processed by software with little impact on average performance. Principle 3 pretty much follows from 1 and 2. Since network layer security information is interpreted only by the destination host, by principle 2 it just doesn't belong in the IP header. Putting it there anyway could well violate 3, especially since many sites might well opt to run without network layer security even if it is widely available. By the way, some years ago I originally proposed adding authentication to IP as an IP header option. Jeff Schiller talked me out of it, and he was correct. As for the layer 3/4 controversy, I think it shows that there's a need for both. Layer 3 security is arguably much more flexible and complete. It covers and protects any arbitrary transport protocol. E.g., authentication between TCP and IP protects TCP against maliciously generated spurious RSTs and connection hijacking. If the authenticator includes a timestamp, it could protect against long-delayed replay attacks (defense against short-term replay would still be the responsibility of the transport protocol, but this is something it has to defend against anyway since the Internet can duplicate packets occasionally on its own.) And if encryption is used, an eavesdropper is denied the maximal amount of information. All he sees is traffic between two hosts; he can't tell what application or even what transport protocol is in use. The only problem I can see with layer 3 security has to do with efficiency. For example, it breaks Van Jacobson TCP/IP header compression. Some slow serial line users might not be willing to give this up to gain all of the benefits of network layer security. If they're mainly interested in confidentiality, then they could simply run a stream cipher on top of TCP. This could be part of the application (as it is in Kerberos) or it could become a TCP option. This would make security an optional level 4 service. Phil From smb@research.att.com Tue Dec 1 13:32:42 1992 Received: from interlock.ans.net by nis.ans.net with SMTP id AA51727 (5.65c/IDA-1.4.4 for ); Tue, 1 Dec 1992 18:26:37 -0500 Received: from research.att.com by interlock.ans.net with SMTP id AA29971 (InterLock SMTP Gateway 1.1 for ); Tue, 1 Dec 1992 18:32:34 -0500 Message-Id: <199212012332.AA29971@interlock.ans.net> From: smb@research.att.com To: karn@qualcomm.com (Phil Karn) Cc: atkinson@tengwar.itd.nrl.navy.mil, kasten@ftp.com, ipsec@ans.net Subject: Re: Network Layer Security Properties Date: Tue, 01 Dec 92 18:32:42 EST As for the layer 3/4 controversy, I think it shows that there's a need for both. Layer 3 security is arguably much more flexible and complete. It covers and protects any arbitrary transport protocol. E.g., authentication between TCP and IP protects TCP against maliciously generated spurious RSTs and connection hijacking. If the authenticator includes a timestamp, it could protect against long-delayed replay attacks (defense against short-term replay would still be the responsibility of the transport protocol, but this is something it has to defend against anyway since the Internet can duplicate packets occasionally on its own.) We're going to have to be careful about our terminology here, and in particular when we use phrases like ``layer 3'' or ``layer 4'' security. SP4, for example, attaches on the *bottom* of layer 4. That is, the TP4 or TCP header is encrypted and thus protected from introduction of spurious RST's and the like. Similarly, SP3 is attached to the bottom of IP (or rough equivalent), thereby protecting (in some configurations) even the source and destination IP address. The real differences for these two are (a) the granularity of protection, and (b) where they can be deployed. SP4 will guard individual connections, making it useful for high-security hosts. SP3 provides protection only to the level of the host, but for many current machines, that's quite sufficient. Also, it can be deployed on routers and gateways, not just hosts. That's both good and bad. It's good, because routers are generally more secure than hosts, and are fewer in number, making them easier to upgrade; it's bad, because the granularity of protection is then the entire network behind the gateway. (Of course, in many configurations, all such machines have to be considered part of the same security domain anyway.) --Steve Bellovin From karn@qualcomm.com Tue Dec 1 14:17:43 1992 Received: from interlock.ans.net by nis.ans.net with SMTP id AA42971 (5.65c/IDA-1.4.4 for ); Wed, 2 Dec 1992 01:20:04 -0500 Received: from qualcomm.com (qualcom.qualcomm.com) by interlock.ans.net with SMTP id AA23429 (InterLock SMTP Gateway 1.1 for ); Wed, 2 Dec 1992 01:17:17 -0500 Received: from servo.qualcomm.com by qualcomm.com; id AA22145 sendmail 5.65/QC-main-2.1 via SMTP Tue, 1 Dec 92 22:17:44 -0800 for ipsec@ans.net Received: by servo; id AA27140 sendmail 5.67/QC-subsidiary-2.1 Tue, 1 Dec 92 22:17:43 -0800 for ipsec@ans.net Date: Tue, 1 Dec 92 22:17:43 -0800 From: karn@qualcomm.com (Phil Karn) Message-Id: <9212020617.AA27140@servo> To: dee@ranger.enet.dec.com, karn@qualcomm.com Subject: RE: Re: IPSEC & ROAD Cc: ipsec@ans.net >From: "Donald E. Eastlake, III, LJO2/I4 +1 508 486 2358 30-Nov-1992 1632" >(1) You would like to authenicate ICMP messages (redirects, quenches, >etc.), DNS responses (even if the query isn't authenticated), etc. This >requires some way to sign the datagram, perhaps with an RSA signed digest like >thing. However, you don't want to have to negotiate this with the destination >and would like things to "work" even if the destination is ignorant of the >security protocol. Hmm. At first glance this does seem like a good argument for an IP authentication option. But I see some significant practical obstacles. Having routers and DNS servers sign responses to packets from J. Random Host requires public key cryptography. And to do it on a one-shot basis, a (slow) RSA secret key operation is probably required for each one. It's not clear you'd want to spend all those cycles on every single message, especially when you don't even know if the recipient can make use of it. It could also open up a whole new class of denial-of-service attacks based on overwhelming a node's signing ability. And if you protect yourself by limiting the rate at which signatures can be generated, then you will necessarily leave the signatures off responses to legitimate messages. This is not to say that it wouldn't be useful to sign standalone ICMP and DNS messages, only that it might not be practical in the near future. In comparison, the kind of bidirectional communication that I envision as the primary use of an IP security protocol would allow the host pairs to sign their packets with a fast single-key algorithm like keyed MD-5, using keys created and cached for some reasonable period of time (e.g., at least 10 minutes). That means you'd only need to do the slow RSA secret key operation once when the hosts first begin talking and at most once every 10 minutes as long as the association remains active. This is much more practical, especially since the signing wouldn't take place unless both parties agree first to use it. One could envision a negotiation that begins with the recipient of an unsigned datagram sending a message that says "Sorry, unauthenticated datagrams of this type are not accepted by this host. Please initiate a key exchange." The negotiation could also determine whether encryption is used. And once you have this whole mechanism in place (which would fit nicely into a separate protocol, without requiring an IP option), there's no reason why it couldn't also be used to sign the occasional ICMP and DNS response. Phil From teb@saturn.sys.acc.com Wed Dec 2 02:59:56 1992 Received: from interlock.ans.net by nis.ans.net with SMTP id AA48513 (5.65c/IDA-1.4.4 for ); Wed, 2 Dec 1992 07:56:27 -0500 Received: from POLLUX.SYS.ACC.COM by interlock.ans.net with SMTP id AA19419 (InterLock SMTP Gateway 1.1 for ); Wed, 2 Dec 1992 08:00:56 -0500 Received: from saturn.sys.acc.com by pollux.sys.acc.com (4.1/SMI-4.1) id AA04082; Wed, 2 Dec 92 04:57:45 EST Received: by saturn.sys.acc.com (5.51/5.17) id AA11117; Wed, 2 Dec 92 07:59:56 EST Date: Wed, 2 Dec 92 07:59:56 EST From: teb@saturn.sys.acc.com (Tom Benkart) Message-Id: <9212021259.AA11117@saturn.sys.acc.com> To: ipsec@ans.net Subject: Where does security belong? I'd like to second Phil's comments about the "appropriate" place for security in the protocol stack. Restricting information at the IP layer to only that which is needed by end AND intermediate (router) systems is my strong preference. Not very much security- related information falls into this category. Unfortunately, we may not have much choice, since only IP is up for redesign at this time (I agree that the current option size limit in IPv4 will limit what we can do in the current version). Is it feasible to suggest adding new TCP/UDP/??? options? If something like PIP is chosen as IPv7, maybe whatever the routers needed could be included in the Handling Directives, whereas information only needed by the end systems could be ignored by the routers. The other IPv7 proposals don't have anything like a "router sublayer". Most of the discussion so far has centered around authentication, integrity and confidentiality. By my criteria from the first paragraph, none of these *have* to be handled at the IP level. Conspicuously absent from the discussion is any mention of access control, which would have to be done at the IP level since routers might need to restrict routes based on that information. It is also interesting that access control is about the only thing the current RIPSO/CIPSO provides. Is the lack of mention of access control because no one really wants/needs it, or because it is assumed as a given? Tom Benkart ACC Systems From smb@research.att.com Wed Dec 2 03:54:55 1992 Received: from interlock.ans.net by nis.ans.net with SMTP id AA43689 (5.65c/IDA-1.4.4 for ); Wed, 2 Dec 1992 08:50:08 -0500 Received: from research.att.com by interlock.ans.net with SMTP id AA03460 (InterLock SMTP Gateway 1.1 for ); Wed, 2 Dec 1992 08:54:42 -0500 Message-Id: <199212021354.AA03460@interlock.ans.net> From: smb@research.att.com To: teb@saturn.sys.acc.com (Tom Benkart) Cc: ipsec@ans.net Subject: Re: Where does security belong? Date: Wed, 02 Dec 92 08:54:55 EST Conspicuously absent from the discussion is any mention of access control, which would have to be done at the IP level since routers might need to restrict routes based on that information. It is also interesting that access control is about the only thing the current RIPSO/CIPSO provides. Is the lack of mention of access control because no one really wants/needs it, or because it is assumed as a given? In a complex network, RIPSO/CIPSO do no good without encryption or at least authentication. If you can't can't trust parts of the network, you can't trust them not to insert bogus security options. If your topology is restricted enough, you might be ok -- but that's not the general case. Part of the specs for things like SP3 include looking at the security label to pick the appropriate skey, so they do interact. From atkinson@tengwar.itd.nrl.navy.mil Wed Dec 2 04:01:03 1992 Received: from interlock.ans.net by nis.ans.net with SMTP id AA46678 (5.65c/IDA-1.4.4 for ); Wed, 2 Dec 1992 08:56:51 -0500 Received: from tengwar.itd.nrl.navy.mil by interlock.ans.net with SMTP id AA08638 (InterLock SMTP Gateway 1.1 for ); Wed, 2 Dec 1992 09:01:06 -0500 Message-Id: <199212021401.AA08638@interlock.ans.net> Received: by tengwar.itd.nrl.navy.mil (16.8/16.2) id AA08241; Wed, 2 Dec 92 09:01:03 -0500 From: atkinson@tengwar.itd.nrl.navy.mil (Randall Atkinson) Date: Wed, 2 Dec 1992 09:01:03 EST In-Reply-To: teb@saturn.sys.acc.com (Tom Benkart) "Where does security belong?" (Dec 2, 7:59am) X-Mailer: Mail User's Shell (7.2.3 5/22/91) To: teb@saturn.sys.acc.com (Tom Benkart) Subject: Re: Where does security belong? Cc: big-Internet@munnari.oz.au, ipsec@ans.net On Dec 2, 7:59am, Tom Benkart wrote: } I'd like to second Phil's comments about the "appropriate" place } for security in the protocol stack. Restricting information at } the IP layer to only that which is needed by end AND intermediate } (router) systems is my strong preference. I don't think there is any single place in the protocol stack that has an exclusive on security. My understanding is that the current work in ipsec is on security for IPv4 (with perhaps an eye towards SIP/PIP/CLNP/etc). Working on IP level security need not preclude subsequent or parallel work at other layers. There has already been discussion of handling key management in parallel and possibly doing it at a different layer in the stack (I *do* hope that work proceeds in parallel rather than being deferred). } Not very much security-related information falls into this category. Not sure what this means. See below. } Most of the discussion so far has centered around authentication, } integrity and confidentiality. By my criteria from the first } paragraph, none of these *have* to be handled at the IP level. I disagree, by your own criteria, there are many that HAVE to be handled at the IP level. For example, without some kind of authentication in ICMP, there are a very large number of attacks on both end systems and intermediate systems (Super Source Quench is only one example). Policy-based routing (which would be of significant value to the Navy and probably also most commercial network service providers) cannot be reliably implemented unless there is some mechanism which provides assurance that the information used to make the routing decision is in fact authentic and not forged. Policy-based routing would probably depend on the source of the traffic as well as the destination and might also depend on QOS information. There are numerous other examples that directly relate. } Conspicuously absent from the discussion is any mention of access } control, which would have to be done at the IP level since routers } might need to restrict routes based on that information. It is } also interesting that access control is about the only thing the } current RIPSO/CIPSO provides. Is the lack of mention of access } control because no one really wants/needs it, or because it is } assumed as a given? RIPSO/CIPSO do NOT provide access control. That is a myth or perhaps "aggressive marketing" -- depending on one's perspective about marketing. The RIPSO/CIPSO options provide unauthenticated label information on the sensitivity of the data in the IP datagram. The CIPSO folks have strongly resisted efforts to add more descriptive language to their draft clarifying how to handle packets that are out of range and so forth -- so the CIPSO draft doesn't even provide any requirements on access control in the end system, let alone distinguishing the intermediate router case. What the receiving host with the arriving packet is not fully specified -- most trusted systems will map the received sensitivity label into an internal-to-the-OS sensitivity label and make MAC decisions based on the OS label. Moreover, it is almost trivial to modify the RIPSO/CIPSO label on the fly (i.e. while the packet is in transit). Without some authentication mechanism for the CIPSO/RIPSO information, one can not make any kind of dependable access control decision based on the information in that label. Optional support for some kind of authentication (whether bundled with confidentiality or also available separately) is clearly needed. Integrity and confidentiality properties are also desired by many, at least optionally (regardless of whether one has an IP option or optionally encapsulates IP into another security protocol). Ran atkinson@itd.nrl.navy.mil -- From Paul_Lambert@poncho.phx.sectel.mot.com Wed Dec 2 02:49:55 1992 Received: from interlock.ans.net by nis.ans.net with SMTP id AA42908 (5.65c/IDA-1.4.4 for ); Wed, 2 Dec 1992 11:41:55 -0500 Received: from motgate.mot.com by interlock.ans.net with SMTP id AA37462 (InterLock SMTP Gateway 1.1 for ); Wed, 2 Dec 1992 11:47:46 -0500 Received: from pobox.mot.com ([129.188.137.100]) by motgate.mot.com with SMTP (5.65c/IDA-1.4.4/MOT-2.5 for ) id AA08318; Wed, 2 Dec 1992 10:48:13 -0600 Received: from phx.sectel.mot.com ([192.94.147.2]) by pobox.mot.com with SMTP (5.65c/IDA-1.4.4/MOT-2.5 for ) id AA23078; Wed, 2 Dec 1992 10:48:10 -0600 Received: from poncho.phx.sectel.mot.com by phx.sectel.mot.com (4.1/SMI-4.1) id AA03448; Wed, 2 Dec 92 09:45:29 MST Received: from SECTEL (QM 2.5.1) by poncho.phx.sectel.mot.com (SMTP\QM 1.1.3) id AA29267; Wed, 2 Dec 1992 9:53:07 MST Message-Id: <00112.2806134787.29267@poncho.phx.sectel.mot.com> X-Charset: MACINTOSH To: ipsec@ans.net (ipsec) From: Paul_Lambert@poncho.phx.sectel.mot.com (Paul Lambert) Date: Wed, 2 Dec 1992 9:49:55 MST Subject: Re: >Draft Charter IPSEC WG Reply to: RE>>Draft Charter IPSEC WG There have been numerous comments suggesting that Rkey managementS be removed from IPSEC. As one of the authors of the draft charter I would like to explain and defend the inclusion of the key management tasks. >Given the ongoing work in CAT and PEM has significant key management >aspects, I wonder if a separate WG might be a good place to develop a >key management protocol that is already proposed to live in the >application layer? I would hate to see the network layer focus of >this WG cause a key management protocol to arise which might be too >layer 3-centric. Of course close co-ordination would need to be >maintained between two the WGs if a separate KM WG was formed, to >ensure that the resulting protoco, adequately supports the >requirements of a layer 3 security protocol. > >Steve and... >Why not setup a parallel WG to work on the key mgmt aspects >while the IP Security WG works on the authentication/confidentiality >mechanisms for IP ?? > >Ran Considerable discussion of key management went into the creation of the schedule and milestones for IPSEC. The intent was to ensure that the milestones included a "complete" and workable "ip security" solution. Relying on another, yet to be formed group did not seem to be a viable plan. The base work for Rnetwork securityS is quite mature and the March 93 milestone for a draft of this specification is reasonable. Most of this work has had little visibility in the Internet community, but has been extensively documented (as SP3 and NLSP). At least five commercial implementations (non-interoperable) have been fielded. The SP3/NLSP security is quite straightforward for host-to-host implementations. March 93 was also set as a milestone for selecting a direction for key management that would support the lower layer security mechanism. Perhaps the text in the charter for an: R Initial framework for Internet key management techniquesS is phrased in too broad of terms. This might have been phrased better to - define the requirements and select an initial approach to provide key management for ipsec The area of key management is also a well worked, but immature technical area. The related existing work includes: IEEE 802.10C, ISO GULS, IETF CAT, SNMP, SDNS KMP, and ANSI X9.xx. The intent was not to reinvent, but to hopefully adopt , adapt, or build upon existing work. After the definition of the simplier host-to-host signaling, the subnet-to-subnet issues will be confronted. I feel that it is critical that a single working group investigate both key management and the network layer issues. Many of the possible solutions for the interesting subnet security issues are provided by a close coupling with key management. The final milestones include the development of prototypes for subnet-to-subnet security mechanisms. Interoperabilty can only be guarenteed if both the lower layer protocol and key management signaling interoperate. Rather than prematurely restraining the working group I suggest that we proceed with discussions of key management requirements for ipsec within this forum. Paul From Paul_Lambert@poncho.phx.sectel.mot.com Wed Dec 2 03:05:49 1992 Received: from interlock.ans.net by nis.ans.net with SMTP id AA48633 (5.65c/IDA-1.4.4 for ); Wed, 2 Dec 1992 11:53:58 -0500 Received: from motgate.mot.com by interlock.ans.net with SMTP id AA14988 (InterLock SMTP Gateway 1.1 for ); Wed, 2 Dec 1992 11:59:24 -0500 Received: from pobox.mot.com ([129.188.137.100]) by motgate.mot.com with SMTP (5.65c/IDA-1.4.4/MOT-2.5 for ) id AA08723; Wed, 2 Dec 1992 10:59:51 -0600 Received: from phx.sectel.mot.com ([192.94.147.2]) by pobox.mot.com with SMTP (5.65c/IDA-1.4.4/MOT-2.5 for ) id AA23608; Wed, 2 Dec 1992 10:59:48 -0600 Received: from poncho.phx.sectel.mot.com by phx.sectel.mot.com (4.1/SMI-4.1) id AA03451; Wed, 2 Dec 92 09:57:09 MST Received: from SECTEL (QM 2.5.1) by poncho.phx.sectel.mot.com (SMTP\QM 1.1.3) id AA29269; Wed, 2 Dec 1992 10:06:03 MST Message-Id: <00112.2806135563.29269@poncho.phx.sectel.mot.com> X-Charset: MACINTOSH To: ipsec@ans.net (ipsec) From: Paul_Lambert@poncho.phx.sectel.mot.com (Paul Lambert) Date: Wed, 2 Dec 1992 10:05:49 MST Subject: Re: >Draft Charter RE>>Draft Charter >Simple question: Do you and others believe that you have the >gist of the 2 solutions (net-layer protocol and key protocol) already >fleshed out or do you expect substantial haggling about basic >approaches? > >If the former applies, then I believe your schedule. If the latter >applies, then you have a heck of a challenge ahead. (Hmmm. I suspose >you have _that_ no matter what.) > >Dave The charter is a little bit ambiguous to allow open discussion of all alternatives. However, I believe the gist of the two solutions is: - an adaptation of the ISO DIS 11577 Network Layer Security Protocol (NLSP) to support net-layer security, and - an adaptation of the draft IEEE 802.10C key management In the case of NLSP, adaptation means that we have discussed approaches that NLSP could be: a) used as is , (not yet feasible since the current elements of procedure donUt work for the Internet), b) modified to support a next protocol field, c) qualified to utilize the NSEL of included NSAPS (much like SP3-A), d) harmonized with a convergence protocol to encapsulate Internet protocols, or e) combinations and hybrids of the above. The work required in the ipsec working group to use IEEE 802.10C (or similar work) would include: a) profiling the protocol for the Internet, b) supporting shared key distribution for broadcast/multicast datagrams, c) supporting NLSP peer-entity authentication and protocol option negotiation, Paul From atkinson@tengwar.itd.nrl.navy.mil Wed Dec 2 08:04:11 1992 Received: from interlock.ans.net by nis.ans.net with SMTP id AA22470 (5.65c/IDA-1.4.4 for ); Wed, 2 Dec 1992 12:56:45 -0500 Received: from tengwar.itd.nrl.navy.mil by interlock.ans.net with SMTP id AA22944 (InterLock SMTP Gateway 1.1 for ); Wed, 2 Dec 1992 13:03:44 -0500 Received: by tengwar.itd.nrl.navy.mil (16.8/16.2) id AA08939; Wed, 2 Dec 92 13:04:11 -0500 From: atkinson@tengwar.itd.nrl.navy.mil (Ran Atkinson) Message-Id: <9212021304.ZM8937@tengwar.itd.nrl.navy.mil> Date: Wed, 2 Dec 1992 13:04:11 -0500 In-Reply-To: Paul_Lambert@poncho.phx.sectel.mot.com (Paul Lambert) "Re: >Draft Charter" (Dec 2, 10:05) References: <00112.2806135563.29269@poncho.phx.sectel.mot.com> Organisation: Naval Research Laboratory X-Mailer: Z-Mail (2.1.0 10/27/92) To: Paul_Lambert@poncho.phx.sectel.mot.com (Paul Lambert) Subject: Re: IPSEC starting point Cc: ipsec@ans.net It seemed to me like we ought to _at least_ seriously consider using the SDNS work, including the SDNS Key Mgmt mechanisms, as a good base to work from. Other considerations aside, a lot of work has been done on that and as near as I can tell, all of the US DoD will be moving in an SDNS-like direction (which means that leveraging that work should help the availability of commercial implementations that would eventually [preferably soon] be really interoperable. I haven't studied the SP3 and NLSP documents side by side recently, but am doing so now. If someone had an existing summary of differences that they could post to this list, it would be generally useful, I think. Ran atkinson@itd.nrl.navy.mil From Paul_Lambert@poncho.phx.sectel.mot.com Thu Dec 3 03:36:47 1992 Received: from interlock.ans.net by nis.ans.net with SMTP id AA28699 (5.65c/IDA-1.4.4 for ); Thu, 3 Dec 1992 12:25:31 -0500 Received: from motgate.mot.com by interlock.ans.net with SMTP id AA12419 (InterLock SMTP Gateway 1.1 for ); Thu, 3 Dec 1992 12:30:25 -0500 Received: from pobox.mot.com ([129.188.137.100]) by motgate.mot.com with SMTP (5.65c/IDA-1.4.4/MOT-2.5) id AA15655; Thu, 3 Dec 1992 11:30:52 -0600 Received: from phx.sectel.mot.com ([192.94.147.2]) by pobox.mot.com with SMTP (5.65c/IDA-1.4.4/MOT-2.5) id AA18864; Thu, 3 Dec 1992 11:30:49 -0600 Received: from poncho.phx.sectel.mot.com by phx.sectel.mot.com (4.1/SMI-4.1) id AA04886; Thu, 3 Dec 92 10:28:01 MST Received: from SECTEL (QM 2.5.1) by poncho.phx.sectel.mot.com (SMTP\QM 1.1.3) id AA29365; Thu, 3 Dec 1992 10:36:53 MST Message-Id: <00112.2806223813.29365@poncho.phx.sectel.mot.com> X-Charset: MACINTOSH To: gvaudre@CNRI.Reston.VA.US (Greg Vaudreuil), ipsec@ans.net (ip security mailing list) Cc: ahoover@ans.net (Alton Hoover) From: Paul_Lambert@poncho.phx.sectel.mot.com (Paul Lambert) Date: Thu, 3 Dec 1992 10:36:47 MST Subject: Re: FYI IPSEC WG Charter Reply to: RE>FYI IPSEC WG Charter Greg, There have been some constructive comments on the charter in the last week that should be incorporated into the text. I have taken the liberty to develop a 2nd draft of the charter that incorporates these changes. Following are responses to Joe TardoUs comments, a summary of changes to the charter, and a 2nd draft of the charter. >Now some more constructive comments, on Alton Hoover and Paul Lambert's >Draft charter. > >1. What do you mean by "access control"? Do you mean labelling? Packet > filtering? This should probably not be an early requirement. Access control seemed to be a stronger requirement than confidentiality in the discussions at the last BOF meeting. Access control can readily be based on authenticated host addresses. Options for datagram labeling are possible along with access control decisions based on these labels. All of the services listed in the draft charter can be readily provided by an RipsecS security protocol. All of these services should at least be considered in the initial design. We attempted to qualify the charter to allow various combinations of these services to be supported. >2. Sprinkle "algorithm independence" in somewhere. Ok! Added to the first paragraph of the charter as: The protocol formats for ipsec will be independent of the cryptographic algorithm. >3. What do you mean by "integrity" for a datagram service? This is > a snake pit if you are worried about replay. Integrity can be provided by a Integrity Check Value (ICV). At a minimum IPSEC can provide connection-less integrity without recovery. You are correct that placing sequence numbers in a connection-less protocol to provide complete protection from replay is controversial. The ISO 11577 Network Layer Security Protocol currently attempts to support sequence numbers. Since we can readily provide the simplest connection-less integrity service we should leave this goal in the charter. >4. "Subnet-to-subnet ... recursive ... encapsulation" is a bit too > specific for terms of reference. This was specifically included by one of the contributors to the charter to highlight a specific problem with the current NLSP specification. Currently NLSP does not contain procedures describing the recursive encapsulation of NLSP. You are correct that this is to specific to be in the basic charter. IUve taken this text out of the attached draft. >5. Key management - let's be realistic. I suggest the "minimalist" > (KISS) approach to start: manual keying via SNMP (: duck :) with > a nice little MIB. Next should come a peer-peer exchange in the > layer ("Key Exchange Control Protocol"), something akin to what > Phil Karn (others before him) have suggested, but as lightweight > as possible. Later on (much later) should come the all-singing- > all-dancing-802.10-KMAE-X9.17-compatible-Holy-Grail ultimate one- > size-fits-all key exchange application, if ever. I feel that the goals of the charter for key management are achievable. Particularly if we do keep it simple at first as you suggest. >6. Finally, is it integrated in IP or a sublayer? In other words, is > this limited to "externally observable" interworking issues or are > you going to delve into end-system interface issues? This starts > to get into the "assurance" question... I was pressing strongly for a sublayer approach that would define a security protocol independent from IP. The charter was left slightly ambiguous to leave this open for discussion. While I personally favor this layered encapsulation, it is also possible to integrate any of these cryptographic mechanisms directly into IP or IPv7. It seemed better to not close off this discussion prematurely by becoming overly specific in the charter. >The schedule looks OK for an encapsulating frame, no replay integrity hacks, >SP3-D-based protocol with MIB keying, end-system-to-end-system, no assurance, >no access control or authentication beyond "yup, key works!". The SP3 specification has evolved into the ISO 11577 NLSP specification. The connection-less mode of this document (NLSP-CL) is currently the strongest contender for a Rstarting pointS for IPSEC. Summary of changes to charter Added in the first paragraph: The protocol formats for ipsec will be independent of the cryptographic algorithm. Removed from the first paragraph: Subnet-to-subnet topologies will support recursive cryptographic encapsulation. 2nd Draft - 2nd Draft - 2nd Draft - 2nd Draft - 2nd Draft - 2nd Draft Internet Protocol Security Protocol (ipsec) Charter Chair(s): Al Hoover Paul Lambert Security Area Director(s) Steve Crocker Mailing lists: General Discussion: ipsec@ans.net To Subscribe: ipsec-request@ans.net Archive: ftp.ans.net:~/pub/archive/ipsec Description of Working Group: Rapid advances in communication technology have accentuated the need for security in the Internet. The IP Security protocol working group (IPSEC WG) will develop mechanisms to protect client protocols of IP. A security protocol in the network layer will be developed to provide cryptographic security services that will flexibly support combinations of authentication, integrity, access control, and confidentiality. The protocol formats for ipsec will be independent of the cryptographic algorithm. The preliminary goals will specifically pursue host-to-host security followed by subnet-to-subnet and host-to-subnet topologies. Protocol and cryptographic techniques will also be developed to support the key management requirements of the network layer security. The key management will be specified as an application layer protocol that is independent of the lower layer security protocol. The protocol will initially support public key based techniques. Flexibility in the protocol will allow eventual support of Key Distribution Center (KDC - such as Kerberos) and manual distribution approaches. Goals and Milestones: Mar 93 Post as an Internet Draft the Network Layer Security Protocol. Jul 93 Post as an Interenet Draft the specification for Internet Key Management. Nov 93 Report on Pilot Implementation of the Network Layer Security Protocol. Update Protocol as needed. Mar 94 Report on Pilot implementation of the Internet Key Management Protocol. Update Internet Draft as needed. Jul 94 Submit the Network Layer Security Protocol to the IESG for consideration as a Proposed Standard. Jul 94 Submit the Key Management Protocol to the IESG for consideration as a Proposed Standard. From tt@thor.acc.Virginia.EDU Thu Dec 3 08:54:08 1992 Received: from interlock.ans.net by nis.ans.net with SMTP id AA08952 (5.65c/IDA-1.4.4 for ); Thu, 3 Dec 1992 13:47:21 -0500 Received: from Virginia.EDU (uvaarpa.Virginia.EDU) by interlock.ans.net with SMTP id AA32794 (InterLock SMTP Gateway 1.1 for ); Thu, 3 Dec 1992 13:53:54 -0500 Received: from thor.acc.virginia.edu by uvaarpa.Virginia.EDU id aa00190; 3 Dec 92 13:54 EST Received: by thor.acc.Virginia.EDU (4.0/1.34) id AA01862; Thu, 3 Dec 92 13:54:08 EST Date: Thu, 3 Dec 92 13:54:08 EST From: Tang Tang Message-Id: <9212031854.AA01862@thor.acc.Virginia.EDU> To: ipsec@ans.net Subject: please remove me from the ipsec mailing list Thanks From Paul_Lambert@poncho.phx.sectel.mot.com Thu Dec 3 05:44:40 1992 Received: from interlock.ans.net by nis.ans.net with SMTP id AA22770 (5.65c/IDA-1.4.4 for ); Thu, 3 Dec 1992 14:36:23 -0500 Received: from motgate.mot.com by interlock.ans.net with SMTP id AA22642 (InterLock SMTP Gateway 1.1 for ); Thu, 3 Dec 1992 14:43:21 -0500 Received: from pobox.mot.com ([129.188.137.100]) by motgate.mot.com with SMTP (5.65c/IDA-1.4.4/MOT-2.5 for ) id AA21653; Thu, 3 Dec 1992 13:43:48 -0600 Received: from phx.sectel.mot.com ([192.94.147.2]) by pobox.mot.com with SMTP (5.65c/IDA-1.4.4/MOT-2.5 for ) id AA27049; Thu, 3 Dec 1992 13:43:45 -0600 Received: from poncho.phx.sectel.mot.com by phx.sectel.mot.com (4.1/SMI-4.1) id AA05002; Thu, 3 Dec 92 12:40:57 MST Received: from SECTEL (QM 2.5.1) by poncho.phx.sectel.mot.com (SMTP\QM 1.1.3) id AA29379; Thu, 3 Dec 1992 12:48:34 MST Message-Id: <00112.2806231714.29379@poncho.phx.sectel.mot.com> X-Charset: MACINTOSH To: atkinson@tengwar.itd.nrl.navy.mil (Ran Atkinson) Cc: big-Internet@munnari.oz.au (the big-Internet), ipsec@ans.net (ip security mailing list) From: Paul_Lambert@poncho.phx.sectel.mot.com (Paul Lambert) Date: Thu, 3 Dec 1992 12:44:40 MST Subject: 24 Security Examples Reply to: 24 Security Examples Ran, I agree with your comments about considering the SDNS work. >It seemed to me like we ought to _at least_ seriously consider using the SDNS work, including >the SDNS Key Mgmt mechanisms, as a good base to work from. Other considerations aside, >a lot of work has been done on that and as near as I can tell, all of the US DoD will be moving >in an SDNS-like direction (which means that leveraging that work should help the availability >of commercial implementations that would eventually [preferably soon] be really interoperable. > >I haven't studied the SP3 and NLSP documents side by side recently, but am doing so now. >If someone had an existing summary of differences that they could post to this list, it would >be generally useful, I think. > >Ran >atkinson@itd.nrl.navy.mil However, both NLSP and IEEE 802.10 have already been strongly influenced by SDNS! The Secure Data Network System (SDNS) specifications were released to NIST in 1989 and have not been significantly updated since. The SDNS specification for network layer security (SP3 - Security Protocol layer 3) is the basis for the connection-less mode of the ISO Network Layer Security Protocol (NLSP). The SDNS SP4 (Security Protocol layer 4) is nearly identical to the ISO Transport Layer Security Protocol (TLSP). The IEEE 802.10C work was originally using the SDNS Key Management Protocol as a basis for their key management. SP3 and NLSP both define a new protocol that can be placed in the network layer to provide cryptographic encapsulation of other protocols. The connectionless mode of NLSP was originally nearly identical to the SP3 specification. The major changes in NLSP from SP3 are: - The NLSP clear header was modified to make the first octet be a Protocol ID (PID) that is compliant with the ISO TR 9577 guidelines. Both SP3 and SP4 were defined to share the NSEL of ISO TP. This NSEL limited placement of SP3 to the top (SNICP) of the network layer. The Initial PID (IPID) assigned to NLSP allows it to placed at the bottom, middle or top of the network layer. - The SP3-I and SP3-D header encapsulation modes were replaced by identical functionality that uses the Subsequent PID (SPID) in the data to determine if IP or CLNP has been encapsulated. Note that the cryptographic encapsulation of a complete IP datagram is one approach for subnet-to-subnet protection. TLSP and SP4 both added security directly into the ISO Transport protocol. TLSP differs from SP4 only in the removal of a final sequence number (SP3 has this feature). To illustrate how all of these protocols could encapsulate information I have developed a few examples. First, here are a few examples of ways that NLSP might operate at the network layer. a) | link | IP | NLSP-CL | TP or TCP(?) or.. | b) | link | CLNP | NLSP-CL | TP or IDRP or TCP or ... | c) | link | IP | NLSP-CL(S-NSAP,D-NSAP)| TCP or UDP or ... | d) | link | IP | NLSP-CL | IP | TCP or UDP or ... | e) | link | CLNP | NLSP-CL | CLNP | TP or IDRP or ... | f) | link | NLSP-CL | any 802.2 SNAP | g) | X.25 | NLSP-CO | any client protocol of X.25 | NLSP has two distinct modes of operation connection-oriented (CO) and connection-less (CL). Much of the ISO specification (DIS 11577) is unreadable because of the CO mechanism. Ipsec, luckily, only needs the connection-less mode of operation. The examples of SP3 encapsulation below are similar to NLSP with two important differences. First, the model for SP3 places it only at the top (SNICP) of the network layer. Second, the IP/SP3/IP modes of encapsulation explicitly define a complete IPv4 header as part of SP3 (the SP3-D mode). h) | link | IP | SP3-N | TP or ? ... | i) | link | CLNP | SP3-N | TP or ? ... | j) | link | IP | SP3-A(S-NSAP,D-NSAP) | TP or TCP or UDP or ... | k) | link | CLNP | SP3-A(S-NSAP,D-NSAP) | TP or TCP or UDP or ... ? | l) | link | IP | SP3-D( IP ) | TP or TCP or UDP or ... | m) | link | CLNP | SP3-I(CLNP ) | TP or TCP or UDP or ... | As an additional point of confusion one mode of SP3 (SP3-N) is identical to one mode of SP4 (SP4-E). This commonalty is an artifact of compromise made to ease the religious wars of layer 3/4 security placement. n) | link | CLNP | TP(SP4-E) | ISO Session etc.. | Some transport layer zealots still feel that SP4-E is viable for ipsec. I still strongly advocate NLSP as a starting point for ipsec, but at this early stage it might be useful to examine the encapsulation characteristics of ipsec. To provide host-to-host security the following example of ipsec protocol encapsulation seems reasonable. o) | link | IPv4 | IPSEC | any client protocol of IP | p) | link | IPv7 | IPSEC | any client protocol of IP | Alternatives for IPSEC encapsulation for host-to-subnet and subnet-to- subnet security include example o & p above along with: s) | link | IPv4 | IPSEC | IPv4 | any client protocol of IP | t) | link | IPv4 | IPSEC | IPv7 | any client protocol of IP | u) | link | IPv7 | IPSEC | IPv4 | any client protocol of IP | v) | link | IPv7 | IPSEC | IPv7 | any client protocol of IP | w) | link | IP | IPSEC(S-addr,D-addr) | any client protocol of IP | Given that proposals exist for installing NLSP directly over IEEE 802.2 the following example is of interest. This application is beyond the charterUs scope of protecting clients of IP. x) | link | IPSEC | any 802.2 SNAP | Recursive cryptographic encapsulation is yet another example to consider. y) | link | IP |IPSEC|IPSEC|... | any client of IP including IPSEC | Finally, we should recognize the suggestions to embed cryptographic security directly into IPv7. z) | link | IPv7(IPSEC) | any client protocol of IP | The only advantage of embedding ipsec into IPv7 would be in saving a few bytes of header information. There are more permutations of the examples above, but IUve run out of letters. Paul From Paul_Lambert@poncho.phx.sectel.mot.com Thu Dec 3 11:22:50 1992 Received: from interlock.ans.net by nis.ans.net with SMTP id AA30185 (5.65c/IDA-1.4.4 for ); Thu, 3 Dec 1992 20:14:06 -0500 Received: from motgate.mot.com by interlock.ans.net with SMTP id AA21937 (InterLock SMTP Gateway 1.1 for ); Thu, 3 Dec 1992 20:20:33 -0500 Received: from pobox.mot.com ([129.188.137.100]) by motgate.mot.com with SMTP (5.65c/IDA-1.4.4/MOT-2.5) id AA03298; Thu, 3 Dec 1992 19:21:01 -0600 Received: from phx.sectel.mot.com ([192.94.147.2]) by pobox.mot.com with SMTP (5.65c/IDA-1.4.4/MOT-2.5) id AA13427; Thu, 3 Dec 1992 19:20:58 -0600 Received: from poncho.phx.sectel.mot.com by phx.sectel.mot.com (4.1/SMI-4.1) id AA05377; Thu, 3 Dec 92 18:18:12 MST Received: from SECTEL (QM 2.5.1) by poncho.phx.sectel.mot.com (SMTP\QM 1.1.3) id AA29425; Thu, 3 Dec 1992 18:25:59 MST Message-Id: <00112.2806251959.29425@poncho.phx.sectel.mot.com> X-Charset: MACINTOSH To: ahoover@ans.net (Al Hoover), gvaudre@CNRI.Reston.VA.US (Greg Vaudreuil), ipsec@ans.net (ip security mailing list) From: Paul_Lambert@poncho.phx.sectel.mot.com (Paul Lambert) Date: Thu, 3 Dec 1992 18:22:50 MST Subject: yet another protocol for ne Subject: yet another protocol for network security Message: In the last draft of the charter the milestones were changed to specifically call out a Network Layer Security Protocol. >Goals and Milestones: > > Mar 93 Post as an Internet Draft the Network Layer Security Protocol. When we created the draft we did not use this name since it is already the name of the ISO 11577 protocol. We may reference and use portions of this specification, but we will not post it directly as an Internet Draft. The milestone as stated may create a little bit of confusion. Does this matter to anyone? If so, we should change the name .... possibilities include: IP Security Protocol, Internet Security Protocol, Network Security Protocol, Network Layer Security, IP Security, etc... Any preferences on the names? Paul From atkinson@tengwar.itd.nrl.navy.mil Thu Dec 3 15:29:14 1992 Received: from interlock.ans.net by nis.ans.net with SMTP id AA36607 (5.65c/IDA-1.4.4 for ); Thu, 3 Dec 1992 20:21:18 -0500 Received: from tengwar.itd.nrl.navy.mil by interlock.ans.net with SMTP id AA21970 (InterLock SMTP Gateway 1.1 for ); Thu, 3 Dec 1992 20:28:55 -0500 Message-Id: <199212040128.AA21970@interlock.ans.net> Received: by tengwar.itd.nrl.navy.mil (16.8/16.2) id AA10355; Thu, 3 Dec 92 20:29:14 -0500 From: atkinson@tengwar.itd.nrl.navy.mil (Randall Atkinson) Date: Thu, 3 Dec 1992 20:29:14 EST In-Reply-To: Paul_Lambert@poncho.phx.sectel.mot.com (Paul Lambert) "yet another protocol for ne" (Dec 3, 6:22pm) X-Mailer: Mail User's Shell (7.2.3 5/22/91) To: Paul_Lambert@poncho.phx.sectel.mot.com (Paul Lambert) Subject: Re: yet another protocol for ne Cc: ipsec@ans.net "IP Security" has unfortunately already been hijacked for the IP Sensitivity label options and would cause confusion for a lot of people. How about: Secure Internet Protocol to be abbreviated as "Secure IP" Ran atkinson@itd.nrl.navy.mil -- From dee@ranger.enet.dec.com Thu Dec 3 15:43:07 1992 Received: from interlock.ans.net by nis.ans.net with SMTP id AA55184 (5.65c/IDA-1.4.4 for ); Thu, 3 Dec 1992 20:37:12 -0500 Received: from inet-gw-2.pa.dec.com by interlock.ans.net with SMTP id AA31768 (InterLock SMTP Gateway 1.1 for ); Thu, 3 Dec 1992 20:45:06 -0500 Received: by inet-gw-2.pa.dec.com; id AA22158; Thu, 3 Dec 92 17:45:33 -0800 Received: by us1rmc.bb.dec.com; id AA13516; Thu, 3 Dec 92 20:43:06 -0500 Message-Id: <9212040143.AA13516@us1rmc.bb.dec.com> Received: from ranger.enet; by us1rmc.enet; Thu, 3 Dec 92 20:43:07 EST Date: Thu, 3 Dec 92 20:43:07 EST From: "Donald E. Eastlake, III, LJO2/I4 +1 508 486 2358 03-Dec-1992 2045" To: paul_lambert@poncho.phx.sectel.mot.com Cc: ipsec@ans.net Apparently-To: ipsec@ans.net, paul_lambert@poncho.phx.sectel.mot.com Subject: RE: yet another protocol for ne I can't hear the phrase "Network Layer" without getting the impression someone is about to spout some OSI stuff. "IP Security Procotol" would be much better. Or, perhaps, "IPv4 Security Protocol". Donald -------------- From: US1RMC::"Paul_Lambert@poncho.phx.sectel.mot.com" "Paul Lambert" 3- DEC-1992 20:28 To: ahoover@ans.net (Al Hoover), gvaudre@CNRI.Reston.VA.US (Greg Vaudreuil), ipsec@ans.net (ip security mailing list) CC: Subj: yet another protocol for ne Subject: yet another protocol for network security Message: In the last draft of the charter the milestones were changed to specifically call out a Network Layer Security Protocol. >Goals and Milestones: > > Mar 93 Post as an Internet Draft the Network Layer Security Protocol. When we created the draft we did not use this name since it is already the name of the ISO 11577 protocol. We may reference and use portions of this specification, but we will not post it directly as an Internet Draft. The milestone as stated may create a little bit of confusion. Does this matter to anyone? If so, we should change the name .... possibilities include: IP Security Protocol, Internet Security Protocol, Network Security Protocol, Network Layer Security, IP Security, etc... Any preferences on the names? Paul From kent@BBN.COM Thu Dec 3 16:38:50 1992 Received: from interlock.ans.net by nis.ans.net with SMTP id AA14013 (5.65c/IDA-1.4.4 for ); Thu, 3 Dec 1992 21:34:08 -0500 Received: from CCV1.BBN.COM by interlock.ans.net with SMTP id AA26908 (InterLock SMTP Gateway 1.1 for ); Thu, 3 Dec 1992 21:38:43 -0500 Message-Id: <199212040238.AA26908@interlock.ans.net> To: smb@research.att.com Cc: Phil Karn , atkinson@tengwar.itd.nrl.navy.mil, kasten@ftp.com, ipsec@ans.net Subject: Re: Network Layer Security Properties In-Reply-To: Your message of Tue, 01 Dec 92 18:32:42 -0500. <199212012332.AA29971@interlock.ans.net> Date: Thu, 03 Dec 92 21:38:50 -0500 From: Steve Kent Steve, While it is historically true that layer 3 protection has been described in terms of host-level granularity, if one provides the protection in a host (vs. a router) then finer granularity can be provided. The work on NLSP and SP3 has brought this possibility to light. Steve From kent@BBN.COM Thu Dec 3 16:47:16 1992 Received: from interlock.ans.net by nis.ans.net with SMTP id AA20459 (5.65c/IDA-1.4.4 for ); Thu, 3 Dec 1992 21:40:05 -0500 Received: from CCV1.BBN.COM by interlock.ans.net with SMTP id AA21842 (InterLock SMTP Gateway 1.1 for ); Thu, 3 Dec 1992 21:47:02 -0500 Message-Id: <199212040247.AA21842@interlock.ans.net> To: Phil Karn Cc: dee@ranger.enet.dec.com, ipsec@ans.net Subject: Re: IPSEC & ROAD In-Reply-To: Your message of Tue, 01 Dec 92 22:17:43 -0800. <9212020617.AA27140@servo> Date: Thu, 03 Dec 92 21:47:16 -0500 From: Steve Kent Phil, Certainly if hosts open connections to DNS servers and maintain them for a while, the overhead of a secure connection establishment (e.g., at layer 3) might be well amortized. However, single UDP queries don;t fit that sort of model very well. An alternative to dynamically signing DNS records might be to have them signed in advance. There are lots of options here and some careful thought will be needed. Steve From kent@BBN.COM Thu Dec 3 16:54:52 1992 Received: from interlock.ans.net by nis.ans.net with SMTP id AA39023 (5.65c/IDA-1.4.4 for ); Thu, 3 Dec 1992 21:46:27 -0500 Received: from CCV1.BBN.COM by interlock.ans.net with SMTP id AA42610 (InterLock SMTP Gateway 1.1 for ); Thu, 3 Dec 1992 21:54:26 -0500 Message-Id: <199212040254.AA42610@interlock.ans.net> To: Tom Benkart Cc: ipsec@ans.net Subject: Re: Where does security belong? In-Reply-To: Your message of Wed, 02 Dec 92 07:59:56 -0500. <9212021259.AA11117@saturn.sys.acc.com> Date: Thu, 03 Dec 92 21:54:52 -0500 From: Steve Kent Tom, The motivation for providing confidentiality, authenticoty, etc. at the IP layer is to provide a uniform tool which can protect a variety of transport protocols (UDP, TCP, ...) and which can be implemented at either end systems or intermediate systems. There is a differenec between arguing about what facilities are appropriate for includion in the IP header or IP option field (an area in which I agree with Phil) vs. a discussion of where to use an encapsulating security protocol in the protoocl stack. Steve From Russ_Housley.McLean_CSD@xerox.com Thu Dec 3 21:15:44 1992 Received: from interlock.ans.net by nis.ans.net with SMTP id AA35256 (5.65c/IDA-1.4.4 for ); Fri, 4 Dec 1992 08:07:51 -0500 Received: from alpha.Xerox.COM by interlock.ans.net with SMTP id AA31927 (InterLock SMTP Gateway 1.1 for ); Fri, 4 Dec 1992 08:15:53 -0500 Received: from ADFMail1.ADFMcLean_CSD.Xerox.xns by alpha.xerox.com via XNS id <11617>; Fri, 4 Dec 1992 05:16:11 PST X-Ns-Transport-Id: 0000AA00A8ECAB392EAF Date: Fri, 4 Dec 1992 05:15:44 PST From: Russ_Housley.McLean_CSD@xerox.com Subject: RE: yet another protocol for ne In-Reply-To: <9212040143.AA13516@us1rmc.bb.dec.com> To: ipsec@ans.net Cc: paul_lambert@poncho.phx.sectel.mot.com Message-Id: <" 4-Dec-92 8:15:29".*.Russ_Housley.McLean_CSD@Xerox.com> I prefer IPSP (IP Security Protocol). Even if the solution turns out to be a specific profile of the NLSP (Network Layer Security Protocol), IPSP is a good name for that profile. Russ From teb@saturn.sys.acc.com Fri Dec 4 04:09:46 1992 Received: from interlock.ans.net by nis.ans.net with SMTP id AA16888 (5.65c/IDA-1.4.4 for ); Fri, 4 Dec 1992 09:02:15 -0500 Received: from POLLUX.SYS.ACC.COM by interlock.ans.net with SMTP id AA22968 (InterLock SMTP Gateway 1.1 for ); Fri, 4 Dec 1992 09:10:09 -0500 Received: from saturn.sys.acc.com by pollux.sys.acc.com (4.1/SMI-4.1) id AA07009; Fri, 4 Dec 92 06:07:00 EST Received: by saturn.sys.acc.com (5.51/5.17) id AA06846; Fri, 4 Dec 92 09:09:46 EST Date: Fri, 4 Dec 92 09:09:46 EST From: teb@saturn.sys.acc.com (Tom Benkart) Message-Id: <9212041409.AA06846@saturn.sys.acc.com> To: ipsec@ans.net Subject: Encapsulation vs options It seems like two different concepts for any "IP security" functionality have been advanced. One involves encapsulation/sublayers, while the other favors true IP options in the IP header itself. Is there real consensus on which way to go? The schedule in the proposed charter assumes SP3/NLSP as a starting point - if we don't agree on marching in that direction, the schedule may not work. Tom Benkart ACC Systems From tardo@tardo.lkg.dec.com Fri Dec 4 04:13:46 1992 Received: from interlock.ans.net by nis.ans.net with SMTP id AA38504 (5.65c/IDA-1.4.4 for ); Fri, 4 Dec 1992 09:05:32 -0500 Received: from mts-gw.pa.dec.com by interlock.ans.net with SMTP id AA33983 (InterLock SMTP Gateway 1.1 for ); Fri, 4 Dec 1992 09:13:38 -0500 Received: by mts-gw.pa.dec.com; id AA29296; Fri, 4 Dec 92 06:13:56 -0800 Received: by tardo.lkg.dec.com (5.57/Ultrix3.0-C) id AA08138; Fri, 4 Dec 92 09:13:47 -0500 Message-Id: <9212041413.AA08138@tardo.lkg.dec.com> To: Paul_Lambert@poncho.phx.sectel.mot.com (Paul Lambert) Cc: ipsec@ans.net (ip security mailing list), atkinson@itd.nrl.navy.mil, Russ_Housley.McLean_CSD@xerox.com, tardo@tardo.lkg.dec.com Subject: What's in a name? In-Reply-To: Your message of "Thu, 03 Dec 92 18:22:50 MST." <00112.2806251959.29425@poncho.phx.sectel.mot.com> Date: Fri, 04 Dec 92 09:13:46 -0500 From: tardo@tardo.lkg.dec.com X-Mts: smtp "IPSP" (IP Security Protocol) is very self-describing, and I personally prefer it. "Secure Internet Protocol" makes a nice RFC title, but hasn't "SIP" already been used, possibly more than once? Avoiding any confusion with respect to NSLP is probably worthwhile, given the direction that document has been taking. -- Joe From atkinson@tengwar.itd.nrl.navy.mil Fri Dec 4 04:29:25 1992 Received: from interlock.ans.net by nis.ans.net with SMTP id AA50144 (5.65c/IDA-1.4.4 for ); Fri, 4 Dec 1992 09:22:00 -0500 Received: from tengwar.itd.nrl.navy.mil by interlock.ans.net with SMTP id AA22547 (InterLock SMTP Gateway 1.1 for ); Fri, 4 Dec 1992 09:29:16 -0500 Message-Id: <199212041429.AA22547@interlock.ans.net> Received: by tengwar.itd.nrl.navy.mil (16.8/16.2) id AA10848; Fri, 4 Dec 92 09:29:25 -0500 From: atkinson@tengwar.itd.nrl.navy.mil (Randall Atkinson) Date: Fri, 4 Dec 1992 09:29:25 EST In-Reply-To: teb@saturn.sys.acc.com (Tom Benkart) "Encapsulation vs options" (Dec 4, 9:09am) X-Mailer: Mail User's Shell (7.2.3 5/22/91) To: teb@saturn.sys.acc.com (Tom Benkart), ipsec@ans.net Subject: Re: Encapsulation vs options I don't think we need to view this as either/or. Clearly we need an encapsulating protocol that is derived from something like NLSP/SP3. That and suitable key mgmt is also clearly the only priority item. However, if some of the mechanisms used there might also be used to create a legitimate security option for IPv4, then why not look into those on the side as a background item without priority. A fair number of folks that I respect say that no such option can be devised for IPv4. I wouldn't be surprised if the result was that nothing ended up happening with an IPv4 option. A look-see in the background couldn't hurt though. Ran atkinson@itd.nrl.navy.mil -- From Russ_Housley.McLean_CSD@xerox.com Thu Dec 3 23:15:30 1992 Received: from interlock.ans.net by nis.ans.net with SMTP id AA16858 (5.65c/IDA-1.4.4 for ); Fri, 4 Dec 1992 10:07:42 -0500 Received: from alpha.Xerox.COM by interlock.ans.net with SMTP id AA41544 (InterLock SMTP Gateway 1.1 for ); Fri, 4 Dec 1992 10:15:41 -0500 Received: from ADFMail1.ADFMcLean_CSD.Xerox.xns by alpha.xerox.com via XNS id <11642>; Fri, 4 Dec 1992 07:15:47 PST X-Ns-Transport-Id: 0000AA00A8ECAB462EAF Date: Fri, 4 Dec 1992 07:15:30 PST From: Russ_Housley.McLean_CSD@xerox.com Subject: Re: Encapsulation vs options In-Reply-To: <9212041409.AA06846@saturn.sys.acc.com> To: teb@saturn.sys.acc.com Cc: ipsec@ans.net Message-Id: <" 4-Dec-92 10:15:21".*.Russ_Housley.McLean_CSD@Xerox.com> Tom: You are absolutely correct. There are two very different concepts being discussed here. At the Thursday IPSEC BOF at the lats IETF, I pointed out that we ad to set "goals" for the group before we could write a charter. Steve Crocker was very vocal in the meeting; he expressed a desire for a simple security protocol for use with IPv4, key management using the infastructure defined for PEM, and quick proof of concept demonstration. Many in the group demanded that the key management approach support more than the PEM certificates, but it was finally agreed that an approach based on PEM certificates would be done first and that other techniques would be done later. These "goals" are reflected in the charter. If these "goals" do not represent the concensus, then the charter must be put on hold until a concensus is reached about the group "goals." Russ From crocker@TIS.COM Fri Dec 4 06:11:46 1992 Received: from interlock.ans.net by nis.ans.net with SMTP id AA37421 (5.65c/IDA-1.4.4 for ); Fri, 4 Dec 1992 11:05:13 -0500 Received: from TIS.COM by interlock.ans.net with SMTP id AA13578 (InterLock SMTP Gateway 1.1 for ); Fri, 4 Dec 1992 11:11:59 -0500 Received: from HAPPY.TIS.COM by TIS.COM (4.1/SUN-5.64) id AA26432; Fri, 4 Dec 92 11:12:04 EST Message-Id: <9212041612.AA26432@TIS.COM> To: Russ_Housley.McLean_CSD@xerox.com Cc: teb@saturn.sys.acc.com, ipsec@ans.net Subject: Re: Encapsulation vs options In-Reply-To: Your message of Fri, 04 Dec 92 07:15:30 -0800. <" 4-Dec-92 10:15:21".*.Russ_Housley.McLean_CSD@Xerox.com> Date: Fri, 04 Dec 92 11:11:46 -0500 From: Stephen D Crocker Russ, Indeed I was vocal and indeed I pushed for limiting the scope of the WG so we have a chance of reaching closure soon. I also said we need key management as well as the data level security protocol so people could actually implement and deploy this in some orderly fashion. Those were my main concerns as Area Director. I also attempted to convey the expectations I have based on my particular view of the world, viz focus on layer 3 versus layer 4, use PEM style certificates. These reflect my individual intuition and taste, but need not be accepted by the group. It's inherent in the process that it's hard to distinguish between things said as an official and things said as an individual. I apologize for not being clearer about this. Steve From Paul_Lambert@poncho.phx.sectel.mot.com Fri Dec 4 03:11:10 1992 Received: from interlock.ans.net by nis.ans.net with SMTP id AA53196 (5.65c/IDA-1.4.4 for ); Fri, 4 Dec 1992 12:05:24 -0500 Received: from motgate.mot.com by interlock.ans.net with SMTP id AA11330 (InterLock SMTP Gateway 1.1 for ); Fri, 4 Dec 1992 12:12:53 -0500 Received: from pobox.mot.com ([129.188.137.100]) by motgate.mot.com with SMTP (5.65c/IDA-1.4.4/MOT-2.5 for ) id AA21777; Fri, 4 Dec 1992 11:13:20 -0600 Received: from phx.sectel.mot.com ([192.94.147.2]) by pobox.mot.com with SMTP (5.65c/IDA-1.4.4/MOT-2.5 for ) id AA13268; Fri, 4 Dec 1992 11:13:17 -0600 Received: from poncho.phx.sectel.mot.com by phx.sectel.mot.com (4.1/SMI-4.1) id AA06122; Fri, 4 Dec 92 10:10:28 MST Received: from SECTEL (QM 2.5.1) by poncho.phx.sectel.mot.com (SMTP\QM 1.1.3) id AA29474; Fri, 4 Dec 1992 10:15:35 MST Message-Id: <00112.2806308935.29474@poncho.phx.sectel.mot.com> X-Charset: MACINTOSH To: dee@ranger.enet.dec.com (Donald E. Eastlake, III, LJO2/), ipsec@ans.net (ip security mailing list) From: Paul_Lambert@poncho.phx.sectel.mot.com (Paul Lambert) Date: Fri, 4 Dec 1992 10:11:10 MST Subject: Re: >yet another protocol fo Reply to: RE>>yet another protocol for No where in our charter do we limit ourselves to IPv4! >I can't hear the phrase "Network Layer" without getting the impression someone >is about to spout some OSI stuff. "IP Security Procotol" would be much better. >Or, perhaps, "IPv4 Security Protocol". > >Donald A well designed encapsulation protocol should work equally well for IPv4 and IPv7. Paul From dee@ranger.enet.dec.com Fri Dec 4 07:49:27 1992 Received: from interlock.ans.net by nis.ans.net with SMTP id AA16859 (5.65c/IDA-1.4.4 for ); Fri, 4 Dec 1992 12:45:11 -0500 Received: from inet-gw-2.pa.dec.com by interlock.ans.net with SMTP id AA31802 (InterLock SMTP Gateway 1.1 for ); Fri, 4 Dec 1992 12:51:30 -0500 Received: by inet-gw-2.pa.dec.com; id AA14109; Fri, 4 Dec 92 09:51:52 -0800 Received: by us1rmc.bb.dec.com; id AA26350; Fri, 4 Dec 92 12:49:24 -0500 Message-Id: <9212041749.AA26350@us1rmc.bb.dec.com> Received: from ranger.enet; by us1rmc.enet; Fri, 4 Dec 92 12:49:27 EST Date: Fri, 4 Dec 92 12:49:27 EST From: "Donald E. Eastlake, III, LJO2/I4 +1 508 486 2358 04-Dec-1992 1251" To: teb@saturn.sys.acc.com Cc: ipsec@ans.net Apparently-To: ipsec@ans.net, teb@saturn.sys.acc.com Subject: RE: Encapsulation vs options Tom, I don't see this as all that big a deal. The security functionality you get with encapsulation and with an option are virtually the same. That decision for IPv4 seems to me to mostly rest on how compatible things will be with the installed base. I favor an option in IPv4 because I think it will work better particularly with the urgent problem of authentication of "control" datagrams. You can even get multiple levels of "encapsulation" easily with an option by just encapsulating IP in IP and specifying the option at more than one level. The exact same fields as are present in such an option could be present in an encapsulating proctol header for SIP or other "IPv7". Whether you use encapsulation or an option, you still have to decide about providing (1) "unilateral" security, (2) negotiated security, or (3) both. (I think both is the only way to go.) You still need to decide about authentication/integrity, time stamps, confidentiality, and maybe even non- denial stuff. You still need to figure out how to specify crypto algorithms and keying techniques (whether unilateral or negotiated) and standardize a few of them so people can interoperate while letting anyone who wants to use their own private algorithms and keying techniques, etc. Donald -------------- From: US1RMC::"teb@saturn.sys.acc.com" "Tom Benkart" 4-DEC-1992 09:16 To: ipsec@ans.net Subj: Encapsulation vs options It seems like two different concepts for any "IP security" functionality have been advanced. One involves encapsulation/sublayers, while the other favors true IP options in the IP header itself. Is there real consensus on which way to go? The schedule in the proposed charter assumes SP3/NLSP as a starting point - if we don't agree on marching in that direction, the schedule may not work. Tom Benkart ACC Systems From atkinson@tengwar.itd.nrl.navy.mil Fri Dec 4 08:24:27 1992 Received: from interlock.ans.net by nis.ans.net with SMTP id AA18703 (5.65c/IDA-1.4.4 for ); Fri, 4 Dec 1992 13:17:39 -0500 Received: from tengwar.itd.nrl.navy.mil by interlock.ans.net with SMTP id AA12578 (InterLock SMTP Gateway 1.1 for ); Fri, 4 Dec 1992 13:24:07 -0500 Received: by tengwar.itd.nrl.navy.mil (16.8/16.2) id AA11217; Fri, 4 Dec 92 13:24:27 -0500 From: atkinson@tengwar.itd.nrl.navy.mil (Ran Atkinson) Message-Id: <9212041324.ZM11215@tengwar.itd.nrl.navy.mil> Date: Fri, 4 Dec 1992 13:24:27 -0500 In-Reply-To: "Donald E. Eastlake, III, LJO2/I4 +1 508 486 2358 04-Dec-1992 1314" "RE: Re: Encapsulation vs options" (Dec 4, 13:12) References: <9212041812.AA27054@us1rmc.bb.dec.com> Organisation: Naval Research Laboratory X-Mailer: Z-Mail (2.1.0 10/27/92) To: "Donald E. Eastlake, III, LJO2/I4 +1 508 486 2358 04-Dec-1992 1314" Subject: RE: Re: Encapsulation vs options Cc: ipsec@ans.net On Dec 4, 13:12, "Donald E. Eastlake, III, LJO2/I4 +1 508 486 2358 wrote: > Subject: RE: Re: Encapsulation vs options >Ran, > >I can't conceive of why someone would think you couldn't design an option. >Just take all the fields in an encapsulating protocol header and stuff them >into an option an there you are. ... >-- End of excerpt from "Donald E. Eastlake, III, LJO2/I4 +1 508 486 2358 There are pretty small limits on the total number of bytes that may be used for options in an IPv4 packet. This is one potential obstacle. A real security option might or might not be practical, desirable, or whatever. Certainly Phil Karn says he doesn't consider it desirable (am I paraphrasing correctly ? :-). I personally think an option might be nice for the vast majority of folks who aren't currently concerned about confidentiality but would like some protection against bogus ICMP or similar attacks. An option clearly isn't the main focus here, but I think it would be nice if it were considered in the background using whatever mechanisms are devised for the encapsulating protocol that really IS the main effort here. Ran atkinson@itd.nrl.navy.mil From Paul_Lambert@poncho.phx.sectel.mot.com Mon Dec 7 02:29:05 1992 Received: from interlock.ans.net by nis.ans.net with SMTP id AA18592 (5.65c/IDA-1.4.4 for ); Mon, 7 Dec 1992 11:25:34 -0500 Received: from motgate.mot.com by interlock.ans.net with SMTP id AA16864 (InterLock SMTP Gateway 1.1 for ); Mon, 7 Dec 1992 11:24:34 -0500 Received: from pobox.mot.com ([129.188.137.100]) by motgate.mot.com with SMTP (5.65c/IDA-1.4.4/MOT-2.5) id AA20744; Mon, 7 Dec 1992 10:25:01 -0600 Received: from phx.sectel.mot.com ([192.94.147.2]) by pobox.mot.com with SMTP (5.65c/IDA-1.4.4/MOT-2.5) id AA24946; Mon, 7 Dec 1992 10:24:58 -0600 Received: from poncho.phx.sectel.mot.com by phx.sectel.mot.com (4.1/SMI-4.1) id AA08196; Mon, 7 Dec 92 09:21:54 MST Received: from SECTEL (QM 2.5.1) by poncho.phx.sectel.mot.com (SMTP\QM 1.1.3) id AA29549; Mon, 7 Dec 1992 9:31:15 MST Message-Id: <00112.2806565475.29549@poncho.phx.sectel.mot.com> X-Charset: MACINTOSH To: crocker@TIS.COM (Stephen D Crocker), gvaudre@CNRI.Reston.VA.US (Greg Vaudreuil) Cc: ahoover@ans.net (Al Hoover), ipsec@ans.net (ip security mailing list) From: Paul_Lambert@poncho.phx.sectel.mot.com (Paul Lambert) Date: Mon, 7 Dec 1992 9:29:05 MST Subject: Final IPSEC Charter Reply to: Final IPSEC Charter Greg and Steve, This should be the final version of the ipsec charter. Only the name of the protocol has been changed to prevent possible confusion with the ISO NLSP. The winner of the informal name contest is IP Security Protocol (IPSP). Paul A. Lambert Motorola, Inc. Internet: Paul_Lambert@email.mot.com 8220 E. Roosevlt Rd. Phone: +1-602-441-3646 Scottsdale, Az. Fax: +1-602-441-8377 85257 USA 4th and Hopefully Final Draft - 4th and Hopefully Final Draft ------------------------------------ Internet Protocol Security Protocol (ipsec) Charter Chair(s): Al Hoover Paul Lambert Security Area Director(s) Steve Crocker Mailing lists: General Discussion: ipsec@ans.net To Subscribe: ipsec-request@ans.net Archive: ftp.ans.net:~/pub/archive/ipsec Description of Working Group: Rapid advances in communication technology have accentuated the need for security in the Internet. The IP Security protocol working group (IPSEC WG) will develop mechanisms to protect client protocols of IP. A security protocol in the network layer will be developed to provide cryptographic security services that will flexibly support combinations of authentication, integrity, access control, and confidentiality. The protocol formats for the IP Security Protocol (IPSP) will be independent of the cryptographic algorithm. The preliminary goals will specifically pursue host-to-host security followed by subnet-to-subnet and host-to- subnet topologies. Protocol and cryptographic techniques will also be developed to support the key management requirements of the network layer security. The key management will be specified as an application layer protocol that is independent of the lower layer security protocol. The protocol will initially support public key based techniques. Flexibility in the protocol will allow eventual support of Key Distribution Center (KDC - such as Kerberos) and manual distribution approaches. Goals and Milestones: Mar 93 Post as an Internet Draft the IP Security Protocol. Jul 93 Post as an Interenet Draft the specification for Internet Key Management. Nov 93 Report on Pilot Implementation of the IP Security Protocol. Update Protocol as needed. Mar 94 Report on Pilot implementation of the Internet Key Management Protocol. Update Internet Draft as needed. Jul 94 Submit the IP Security Protocol to the IESG for consideration as a Proposed Standard. Jul 94 Submit the Key Management Protocol to the IESG for consideration as a Proposed Standard. From dee@skidrow.pa.dec.com Mon Dec 7 08:01:47 1992 Received: from interlock.ans.net by nis.ans.net with SMTP id AA26173 (5.65c/IDA-1.4.4 for ); Mon, 7 Dec 1992 13:03:12 -0500 Received: from inet-gw-1.pa.dec.com by interlock.ans.net with SMTP id AA21624 (InterLock SMTP Gateway 1.1 for ); Mon, 7 Dec 1992 13:01:36 -0500 Received: by inet-gw-1.pa.dec.com; id AA03023; Mon, 7 Dec 92 10:02:00 -0800 Received: by skidrow.ljo.dec.com (5.57/Ultrix3.0-C) id AA12211; Mon, 7 Dec 92 13:01:47 -0500 Message-Id: <9212071801.AA12211@skidrow.ljo.dec.com> Reply-To: dee@skidrow.ljo.dec.com To: ipsec@ans.net Cc: Paul_Lambert@poncho.phx.sectel.mot.com Subject: Re: FWD: Re: FYI IPSEC WG Charter In-Reply-To: Your message of "Thu, 03 Dec 92 13:42:12 EST." Date: Mon, 07 Dec 92 13:01:47 -0500 From: "Beast (Donald E. Eastlake, 3rd)" X-Mts: smtp >2nd Draft - 2nd Draft - 2nd Draft - 2nd Draft - 2nd Draft - 2nd Draft > >Internet Protocol Security Protocol (ipsec) > >Charter > >Chair(s): > Al Hoover > Paul Lambert > >Security Area Director(s) > Steve Crocker > >Mailing lists: > General Discussion: ipsec@ans.net > To Subscribe: ipsec-request@ans.net > Archive: ftp.ans.net:~/pub/archive/ipsec > >Description of Working Group: > >Rapid advances in communication technology have accentuated the need >for security in the Internet. The IP Security protocol working group >(IPSEC WG) will develop mechanisms to protect client protocols of IP. Client protocols seems like a nice way of putting it given that in IP ICMP/DNS/Routing/etc. are all "clients of IP". >A security protocol in the network layer will be developed to provide >cryptographic security services that will flexibly support combinations >of authentication, integrity, access control, and confidentiality. The >protocol formats for ipsec will be independent of the cryptographic >algorithm. The preliminary goals will specifically pursue host-to-host >security followed by subnet-to-subnet and host-to-subnet topologies. Well, while the formats need to be independent of algorithm, they need some way to talk about this so parties can agree on algorithms. If you have a good host-host algorith, you can easily do subnet-to-subnet and host-to-subnet by having the subnet proxy for the hosts. It's only if you want multiple layers of authentication/encryption/etc. that this is somewhat different. I believe that it will be important to keep this possibility in mind and that if this possibility is kept in mind, then there will not be that much work involved in developing a subnet-to-subnet level protocol. An example: Consider a local network with a trusted host T and lots of less trusted workstations W1, W2, ... There might be another such network controlled by the same organization with untrusted lines in between (does not matter if these lines go between adjacent buildings or between continents). Subnet-to-subnet security between the two local networks is basicly the way to go here although you might also have host-host security turned on for all these machines. But lets throw an additional requirement in: the strongly trusted host(s) need to also communicate with some machine(s) M* outside of this cozy arrangement. Either this machine is a source of necessary information to be processed or maybe it's a trusted machine but in any case it is not on a trusted/secure net. So you have this nice strongly trusted machine T that is trapped inside the subnet-to-subnet security so it can't talk to M* . Well, it could have a second hardware network interface to evade this... Or the software on M* could proxy for a secure network but that might require developing special software to do this. But I think the right thing is, in the initial host-to-host protocol to add a "punch-through" bit that requests the supression of all higher levels ("subnet-to-subnet" or the like) of security. Default configuration would be to reject outbound packets with this bit on at the secure subnet level but optionally a secure subnet could be configered to honor this request from one or more trusted hosts in its net (would require outbound packets from that host to be authenticated) and to allow inbound packets addressed to that host that have not had subnet security applied to them (could require host-host security to have been applied to these packets). Anyway, my point is that there may be things like this that could be considered a good idea, but you might not have even thought of it if you did not keep the possibility of an additional level of subnet-to-subnet security in mind. >Protocol and cryptographic techniques will also be developed to support >the key management requirements of the network layer security. The key >management will be specified as an application layer protocol that is >independent of the lower layer security protocol. The protocol will >initially support public key based techniques. Flexibility in the >protocol will allow eventual support of Key Distribution Center (KDC - >such as Kerberos) and manual distribution approaches. I'm not sure exacely what is meant the the above but it seems much too restrictive to me. I think of key management as somewhat orthogonal to cryptographic algorithm. Assuming you have some way for parties negotiating a "secure" (ie, provides one or more of the 4 services listed above) connection to negotiate about the cyrptographic algorithm(s) they are going to use, why can't they also negotiate the key exchange mechanism? There is nothing wrong with a generally accepted applications level protocol; it would be a good thing. But why would something so much simper (if more cumbersome) like manual key distribution, which it seems like you would want to use in debugging the "secure" connection mechanism, come later than an applications level protocol which would be much more complex (although more convenient)? Why not allow the parties just to say to each other that they are assuming manual key distribution as another possibility to applications level public key (certificate, DNS, or whatever)? >Goals and Milestones: > > Mar 93 Post as an Internet Draft the Network Layer Security Protocol. > > Jul 93 Post as an Interenet Draft the specification for Internet Key > Management. > > Nov 93 Report on Pilot Implementation of the Network Layer Security > Protocol. Update Protocol as needed. > > Mar 94 Report on Pilot implementation of the Internet Key Management > Protocol. Update Internet Draft as needed. > > Jul 94 Submit the Network Layer Security Protocol to the IESG for > consideration as a Proposed Standard. > > Jul 94 Submit the Key Management Protocol to the IESG for consideration > as a Proposed Standard. From Russ_Housley.McLean_CSD@xerox.com Mon Dec 7 02:48:30 1992 Received: from interlock.ans.net by nis.ans.net with SMTP id AA05722 (5.65c/IDA-1.4.4 for ); Mon, 7 Dec 1992 13:50:21 -0500 Received: from alpha.Xerox.COM by interlock.ans.net with SMTP id AA32637 (InterLock SMTP Gateway 1.1 for ); Mon, 7 Dec 1992 13:49:22 -0500 Received: from ADFMail1.ADFMcLean_CSD.Xerox.xns by alpha.xerox.com via XNS id <11606>; Mon, 7 Dec 1992 10:49:28 PST X-Ns-Transport-Id: 0000AA00A8ECABD22EAF Date: Mon, 7 Dec 1992 10:48:30 PST From: Russ_Housley.McLean_CSD@xerox.com Subject: Re: FWD: Re: FYI IPSEC WG Charter In-Reply-To: <9212071801.AA12211@skidrow.ljo.dec.com> To: dee@skidrow.ljo.dec.com Cc: ipsec@ans.net Message-Id: <" 7-Dec-92 13:48:00".*.Russ_Housley.McLean_CSD@Xerox.com> Beast (Donald E. Eastlake, 3rd): You raise a good question. To test and demonstrate IPSP, some form of key management must be used, and manual key management will probably be used for this purpose. Therefore, why not include manual key management in the initial RFCs? Russ From dee@skidrow.pa.dec.com Mon Dec 7 09:26:35 1992 Received: from interlock.ans.net by nis.ans.net with SMTP id AA20254 (5.65c/IDA-1.4.4 for ); Mon, 7 Dec 1992 14:27:30 -0500 Received: from inet-gw-1.pa.dec.com by interlock.ans.net with SMTP id AA07300 (InterLock SMTP Gateway 1.1 for ); Mon, 7 Dec 1992 14:25:19 -0500 Received: by inet-gw-1.pa.dec.com; id AA07681; Mon, 7 Dec 92 11:25:42 -0800 Received: by skidrow.ljo.dec.com (5.57/Ultrix3.0-C) id AA12417; Mon, 7 Dec 92 14:26:35 -0500 Message-Id: <9212071926.AA12417@skidrow.ljo.dec.com> Reply-To: dee@skidrow.ljo.dec.com To: ipsec@ans.net Cc: karn@qualcomm.com Subject: Re: FWD: RE: Re: IPSEC & ROAD In-Reply-To: Your message of "Thu, 03 Dec 92 13:42:38 EST." Date: Mon, 07 Dec 92 14:26:35 -0500 From: "Beast (Donald E. Eastlake, 3rd)" X-Mts: smtp >>From: "Donald E. Eastlake, III, LJO2/I4 +1 508 486 2358 30-Nov-1992 1632" > >>(1) You would like to authenticate ICMP messages (redirects, quenches, >>etc.), DNS responses (even if the query isn't authenticated), etc. This >>requires some way to sign the datagram, perhaps with an RSA signed digest lik e >>thing. However, you don't want to have to negotiate this with the destination >>and would like things to "work" even if the destination is ignorant of the >>security protocol. > >Hmm. At first glance this does seem like a good argument for an IP >authentication option. But I see some significant practical obstacles. > >Having routers and DNS servers sign responses to packets from J. >Random Host requires public key cryptography. And to do it on a >one-shot basis, a (slow) RSA secret key operation is probably required >for each one. It's not clear you'd want to spend all those cycles on I don't want you to think that I see this sort of unilateral security as the only way to good. Negotiated security which can use more efficient symetric security will be very important as well. However, I do think that unilateral security is required in some cases to practically maintain the integrity of network operations. Note that the material being authenticated need not include the destination or even the source address, TTL, etc. (However, the source address must be used in determining the authenticity of the message.) If messages are not time stamped, signatures could be precalculated and stored until the data changed or cached when first calculated on demand. Even with time stamps, given the general IPv4 timeout of 4 minutes, you could probably cache them for 2 minutes. It would be intersting to see what fraction of queries received by the top level DNS servers are repeats of other queries within the past few minutes. If a machine has multiple interfaces (ie, IPv4 addresses), the same public key could be associated with them all. Cycles are getting cheap and I think they will be much cheaper by the time any IP security protocol is widely deployed. >every single message, especially when you don't even know if the >recipient can make use of it. It could also open up a whole new class >of denial-of-service attacks based on overwhelming a node's signing >ability. And if you protect yourself by limiting the rate at which >signatures can be generated, then you will necessarily leave the >signatures off responses to legitimate messages. Well, there would be nothing wrong with only signing responses to requests with the security option specified. In the case of DNS queries, you could only sign request that claim to be authenticated but not actually bother at the DNS server to check the authentication, avoiding that effort. Of course, if someone is out to mount a denial of service attack by over whelming you with requests, they would catch on to this right away, but none of this IP security protocol discussion so far has talked about denial of service and I'm not convinced this would make matters that much worse than they are now. There is no way to resist such denial of service attacks in the current Internet. Sure, you can look at the source addresses of requests and ignore those from hosts/networks/whatever that are sending "too many" but then they can forge random source addresses. Presumably that is one of the reasons we want authentication. In fact, the more I think about it, the more it seems like, if this is a problem, you should carefully handle and be sure to respond to authenticated requests that are not an excessive request stream from one source and give unauthenticated requests lower priority. (Might be an interesting strategy to encourage people to implement the security protocol :-) ! ) People can still probably deny service by just fire-hosing packets at you... I realize that what I have said above may make my previous arguments for an option somewhat weaker. However, it still might be useful to have only one cached version with authentication that you send outregardless of the security status of the request. Also, IP was originally designed with options and the software interfaces on many systems are designed for ease in receiving and specifying options. Encapsulation may be "better" in many ways (for example, I think SIP as IPv7 has a lot going for it) but it is frankly installed base hostile. >This is not to say that it wouldn't be useful to sign stand alone ICMP >and DNS messages, only that it might not be practical in the near >future. > >In comparison, the kind of bidirectional communication that I envision >as the primary use of an IP security protocol would allow the host >pairs to sign their packets with a fast single-key algorithm like >keyed MD-5, using keys created and cached for some reasonable period >of time (e.g., at least 10 minutes). That means you'd only need to do >the slow RSA secret key operation once when the hosts first begin >talking and at most once every 10 minutes as long as the association >remains active. This is much more practical, especially since the >signing wouldn't take place unless both parties agree first to use it. I think the type of key exchange you suggest is an excellent idea. The only thing I would suggest is that the key exchange should be considered to be "out of band" and asynchronous with respect to the data transfers which should be tagged with a small "key number" field or something. Thus you could do key rollover without disruption (would be particularly important for attempts at secure isochronous traffic like voice). If you kept the previous key N around for up to 4 minutes after getting a valid datagram using key N+1 (mod field size), you would also have no trouble with re-ordered datagrams. In fact, I think the "exchange" should include agreement on the algorithm(s) to be used, the key management to be used, and the key exchange itself if appropriate (would not, for example, if the agreed upon key management was manual distribution in which case the exchange would just be agreement to use key number N out of the set S of keys that had been manually distributed). With this you could, if you want, have algorithm rollover as well as key rollover. (In case you haven't figured it out, I think sequence numbers are, as they say "Right out!" (ie, a bad idea) for an IP security protocol. Ordering isn't part of the IP level which is what this is suppoed to protect.) >One could envision a negotiation that begins with the recipient of an >unsigned datagram sending a message that says "Sorry, unauthenticated >datagrams of this type are not accepted by this host. Please initiate >a key exchange." The negotiation could also determine whether >encryption is used. And once you have this whole mechanism in place >(which would fit nicely into a separate protocol, without requiring an >IP option), there's no reason why it couldn't also be used to sign >the occasional ICMP and DNS response. I am not sure this is practical. Assume a large net of some sort. Assume a couple of routers. Assume the pipe(s) to the outside world from one of them go down. It has to redirect everything it gets to the other router. If you have an option, the router can calculate authenticated redirects and just send them out. If bilateral security is required, a blizzard of key negotiation and secure connection set up would have to occur, probably enough to drown a lot of real traffic. Of course, I am assuming these hosts have cached the public key for the router or else you get a significant amount of DNS traffic to get it (although the DNS servers involved would all cache the relavent responses)... I am also assuming that the hosts don't already have a bilateral agreement with that router for secure communications... Maybe the real advantage of being able to do things in the manner I have suggest is that there is less state information. With bilateral security, this poor router would have to set up keys with everyone of a possibly huge number of hosts... I certainly think less state information is a good thing and goes with being connectionless.. If a reasonable encapsulating protocol is defined with half an eye to the size limits of options, it does not seem that hard to define an option version of the host-to-host protocol for use where you have not already determined that the other end understands the encapsulating security protocol and its not worth the effort to test this and then maybe negotiate a more efficient algorithm&key because the traffic you want to send is of the nature of an isolated datagram. >Phil This has already run on too long, Thanks if you have read this far, Donald From dee@ranger.enet.dec.com Mon Dec 7 09:27:52 1992 Received: from interlock.ans.net by nis.ans.net with SMTP id AA26371 (5.65c/IDA-1.4.4 for ); Mon, 7 Dec 1992 14:31:03 -0500 Received: from inet-gw-2.pa.dec.com by interlock.ans.net with SMTP id AA23714 (InterLock SMTP Gateway 1.1 for ); Mon, 7 Dec 1992 14:30:04 -0500 Received: by inet-gw-2.pa.dec.com; id AA00606; Mon, 7 Dec 92 11:30:19 -0800 Received: by us1rmc.bb.dec.com; id AA12708; Mon, 7 Dec 92 14:27:51 -0500 Message-Id: <9212071927.AA12708@us1rmc.bb.dec.com> Received: from ranger.enet; by us1rmc.enet; Mon, 7 Dec 92 14:27:52 EST Date: Mon, 7 Dec 92 14:27:52 EST From: "Donald E. Eastlake, III, LJO2/I4 +1 508 486 2358 07-Dec-1992 1430" To: paul_lambert@poncho.phx.sectel.mot.com Cc: ipsec@ans.net Apparently-To: ipsec@ans.net, paul_lambert@poncho.phx.sectel.mot.com Subject: RE: Final IPSEC Charter I'm not sure why this is the 4th as I think I have only previously seen #'s 1 and 2; however, there is little change from 2 so the comments I just sent out continue to apply. Donald 4th and Hopefully Final Draft - 4th and Hopefully Final Draft From dee@ranger.enet.dec.com Mon Dec 7 10:09:14 1992 Received: from interlock.ans.net by nis.ans.net with SMTP id AA58327 (5.65c/IDA-1.4.4 for ); Mon, 7 Dec 1992 15:12:55 -0500 Received: from inet-gw-2.pa.dec.com by interlock.ans.net with SMTP id AA22924 (InterLock SMTP Gateway 1.1 for ); Mon, 7 Dec 1992 15:11:20 -0500 Received: by inet-gw-2.pa.dec.com; id AA03747; Mon, 7 Dec 92 12:11:42 -0800 Received: by us1rmc.bb.dec.com; id AA14224; Mon, 7 Dec 92 15:09:14 -0500 Message-Id: <9212072009.AA14224@us1rmc.bb.dec.com> Received: from ranger.enet; by us1rmc.enet; Mon, 7 Dec 92 15:09:14 EST Date: Mon, 7 Dec 92 15:09:14 EST From: "Donald E. Eastlake, III, LJO2/I4 +1 508 486 2358 07-Dec-1992 1511" To: kent@bbn.com Cc: ipsec@ans.net Apparently-To: ipsec@ans.net, kent@bbn.com Subject: RE: Re: Encapsulation vs options Steve, Well, I think you are now using the word "features" whereas before the word being used was "facilities". More efficient processing by intermediate routers is a feature of encapsulation as is a requirement that the end host be able to speak encapsulation. The ability to fit in with existing option oriented host software is a feature of an option. I don't think I ever claimed that they were identical just that, modulo the limited size of options in IPv4, you could provide virtually the same functional properties with both and there were good reasons to use options in some cases. Donald PS: I'd be interested in more details about what your are thinking about when you talk about directly datagrams to a particular router with crypto capability below. Seems to me that, in the subnet case, you had better put security in all the routers that connect that subnet to the outside world. I suppose you could hack all but one of such routers to forward a datagram that uses the security protocol to one of them that is specially crypto knowledgeable but this would not depend on whether the initial datagram was secured by encapsulation or an option and this forwarding could be done by IP in IP encapsulation and would not necessarily have anything to to with security protocol encapsulation. But maybe I have a complete wrong view of what you were thinking about? -------------- From: US1RMC::"kent@BBN.COM" "Steve Kent" 7-DEC-1992 14:35 To: "Donald E. Eastlake, III,\ LJO2/I4 +1 508 486 2358 04-Dec-1992 1251" CC: teb@saturn.sys.acc.com, ipsec@ans.net Subj: Re: Encapsulation vs options Donald, I don't agree that the IP option and encapsulation approaches are as equivalent as you suggest. This becomes most noticable when an encapsulation protocol is offered at a router vs. an end system. The use of encapsulation makes it easier to direct packets to a particular router (where the crypto capability is located). Also, routers which do not play a role in the crypto processing can avoid seeing the crypto control information if encapsulation is employed, whereas an IP option must be examined by all routers along a path. I don't mean to suggest that there are not good uses for both encapsulation and option-based security, but rather that there are real differences in the features provided by each. Steve From Paul_Lambert@poncho.phx.sectel.mot.com Mon Dec 7 06:49:21 1992 Received: from interlock.ans.net by nis.ans.net with SMTP id AA51255 (5.65c/IDA-1.4.4 for ); Mon, 7 Dec 1992 15:46:18 -0500 Received: from motgate.mot.com by interlock.ans.net with SMTP id AA37131 (InterLock SMTP Gateway 1.1 for ); Mon, 7 Dec 1992 15:44:45 -0500 Received: from pobox.mot.com ([129.188.137.100]) by motgate.mot.com with SMTP (5.65c/IDA-1.4.4/MOT-2.6 for ) id AA02259; Mon, 7 Dec 1992 14:45:11 -0600 Received: from phx.sectel.mot.com ([192.94.147.2]) by pobox.mot.com with SMTP (5.65c/IDA-1.4.4/MOT-2.6 for ) id AA11275; Mon, 7 Dec 1992 14:45:09 -0600 Received: from poncho.phx.sectel.mot.com by phx.sectel.mot.com (4.1/SMI-4.1) id AA08897; Mon, 7 Dec 92 13:42:05 MST Received: from SECTEL (QM 2.5.1) by poncho.phx.sectel.mot.com (SMTP\QM 1.1.3) id AA29576; Mon, 7 Dec 1992 13:50:18 MST Message-Id: <00112.2806581018.29576@poncho.phx.sectel.mot.com> X-Charset: MACINTOSH To: Russ_Housley.McLean_CSD@xerox.com (Russ Housley.McLean CSD), dee@skidrow.ljo.dec.com (Donald E. Eastlake, 3rd), ipsec@ans.net (ip security mailing list) From: Paul_Lambert@poncho.phx.sectel.mot.com (Paul Lambert) Date: Mon, 7 Dec 1992 13:49:21 MST Subject: Re: >FWD- Re- FYI IPSEC WG C Reply to: RE>>FWD: Re: FYI IPSEC WG Ch Donald, Do you have a specific change you would like to see made in the charter, or can your comments be addressed within the scope we have documented? I agree that we need to have some form of *manual* key management for the initial IPSP draft. >>initially support public key based techniques. Flexibility in the >>protocol will allow eventual support of Key Distribution Center (KDC - >>such as Kerberos) and manual distribution approaches. > >I'm not sure exacely what is meant the the above but it seems much too >restrictive to me. I think of key management as somewhat orthogonal >to cryptographic algorithm. Assuming you have some way for parties >negotiating a "secure" (ie, provides one or more of the 4 services >listed above) connection to negotiate about the cyrptographic >algorithm(s) they are going to use, why can't they also negotiate the >key exchange mechanism? There is nothing wrong with a generally >accepted applications level protocol; it would be a good thing. But >why would something so much simper (if more cumbersome) like manual >key distribution, which it seems like you would want to use in >debugging the "secure" connection mechanism, come later than an >applications level protocol which would be much more complex (although >more convenient)? Why not allow the parties just to say to each other >that they are assuming manual key distribution as another possibility >to applications level public key (certificate, DNS, or whatever)? The manual key management for the initial IPSP release could be simple guidelines for setting a local IPSP MIB. I also believe that the *key management protocol* must also support some signaling to announce the availability of manually installed keys. It is this signaling for manual keys within the key management protocol that is described in the charter. Manual key installation will be required to demonstrate the initial host-to-host IPSP, but there will be no new signaling to support this demonstration. I would hope that your comments on the draft charter can all be addressed within the current scope and that we don't need to wordsmith the charter anymore. Paul From Paul_Lambert@poncho.phx.sectel.mot.com Mon Dec 7 07:34:11 1992 Received: from interlock.ans.net by nis.ans.net with SMTP id AA31595 (5.65c/IDA-1.4.4 for ); Mon, 7 Dec 1992 16:30:09 -0500 Received: from motgate.mot.com by interlock.ans.net with SMTP id AA15917 (InterLock SMTP Gateway 1.1 for ); Mon, 7 Dec 1992 16:28:47 -0500 Received: from pobox.mot.com ([129.188.137.100]) by motgate.mot.com with SMTP (5.65c/IDA-1.4.4/MOT-2.6 for ) id AA04422; Mon, 7 Dec 1992 15:29:14 -0600 Received: from phx.sectel.mot.com ([192.94.147.2]) by pobox.mot.com with SMTP (5.65c/IDA-1.4.4/MOT-2.6 for ) id AA14307; Mon, 7 Dec 1992 15:29:12 -0600 Received: from poncho.phx.sectel.mot.com by phx.sectel.mot.com (4.1/SMI-4.1) id AA09030; Mon, 7 Dec 92 14:26:08 MST Received: from SECTEL (QM 2.5.1) by poncho.phx.sectel.mot.com (SMTP\QM 1.1.3) id AA29584; Mon, 7 Dec 1992 14:34:24 MST Message-Id: <00112.2806583664.29584@poncho.phx.sectel.mot.com> X-Charset: MACINTOSH To: dee@ranger.enet.dec.com (dee), ipsec@ans.net (ip security mailing list) From: Paul_Lambert@poncho.phx.sectel.mot.com (Paul Lambert) Date: Mon, 7 Dec 1992 14:34:11 MST Subject: Re: >Final IPSEC Charter Reply to: RE>>Final IPSEC Charter Donald, Sorry for the confusion on the numbering of the ipsec draft charters..... >I'm not sure why this is the 4th as I think I have only previously >seen #'s 1 and 2; however, there is little change from 2 so the >comments I just sent out continue to apply. > >Donald > The draft I send out as the second draft really should have been labeled the third. 19 Nov 92 0th Draft IPSEC Charter - developed over lunch at IETF meeting. 25 Nov 92 1st Draft IPSEC Charter - submitted to ipsec by Alton Hoover. 2 Dec 92 2nd Draft IPSEC Charter - processed and slightly modified by Greg Vaudreuil for IETF Working Group tracking database. Not widely distributed. 3 Dec 92 3rd Draft IPSEC Charter - minor updates (added algorithm independence, removed recursion) based on ipsec comments. Note - this was labeled on the net as draft 2. 7 Dec 92 4th Draft IPSEC Charter - replaced Network Layer Security Protocol references with IP Security Protocol (IPSP). soon Final IPSEC Charter - so far is the same as the 4th, any more constructive comments on the scope defined by the charter? Paul From dee@skidrow.pa.dec.com Mon Dec 7 12:38:30 1992 Received: from interlock.ans.net by nis.ans.net with SMTP id AA51121 (5.65c/IDA-1.4.4 for ); Mon, 7 Dec 1992 17:38:55 -0500 Received: from inet-gw-1.pa.dec.com by interlock.ans.net with SMTP id AA37335 (InterLock SMTP Gateway 1.1 for ); Mon, 7 Dec 1992 17:37:33 -0500 Received: by inet-gw-1.pa.dec.com; id AA16646; Mon, 7 Dec 92 14:37:50 -0800 Received: by skidrow.ljo.dec.com (5.57/Ultrix3.0-C) id AA12968; Mon, 7 Dec 92 17:38:30 -0500 Message-Id: <9212072238.AA12968@skidrow.ljo.dec.com> Reply-To: dee@skidrow.ljo.dec.com To: Paul_Lambert@poncho.phx.sectel.mot.com (Paul Lambert) Cc: Russ_Housley.McLean_CSD@xerox.com (Russ Housley.McLean CSD), dee@skidrow.ljo.dec.com (Donald E. Eastlake, 3rd), ipsec@ans.net (ip security mailing list) Subject: Re: >FWD- Re- FYI IPSEC WG C In-Reply-To: Your message of "Mon, 07 Dec 92 13:49:21 MST." <00112.2806581015.29575@poncho.phx.sectel.mot.com> Date: Mon, 07 Dec 92 17:38:30 -0500 From: "Beast (Donald E. Eastlake, 3rd)" X-Mts: smtp From: Paul_Lambert@poncho.phx.sectel.mot.com (Paul Lambert) >Donald, > >Do you have a specific change you would like to see made in the charter, >or can your comments be addressed within the scope we have documented? > >I agree that we need to have some form of *manual* key management for >the initial IPSP draft. If the current charter is interpreted broadly, and this "application level" key management protocol can be interpreted to allow consideration of DNS retrieval of public keys or agreement via a new protocol number (or with new ICMPs) to either use manual key distribution or securely exchange sessions keys and the like, then I guess I can live with the charter. This means I assume that I can submit a proposal which includes the possibility of host A sending a datagram to host B which is marked as authenticated using a public key retrievable from the DNS and the proposal will not be rejected merely on the grounds that it is outside the charter. Donald From Russ_Housley.McLean_CSD@xerox.com Tue Dec 8 03:45:51 1992 Received: from interlock.ans.net by nis.ans.net with SMTP id AA23626 (5.65c/IDA-1.4.4 for ); Tue, 8 Dec 1992 16:15:31 -0500 Received: from alpha.Xerox.COM by interlock.ans.net with SMTP id AA23127 (InterLock SMTP Gateway 1.1 for ); Tue, 8 Dec 1992 16:14:31 -0500 Received: from ADFMail1.ADFMcLean_CSD.Xerox.xns by alpha.xerox.com via XNS id <11749>; Tue, 8 Dec 1992 11:46:06 PST X-Ns-Transport-Id: 0000AA00A8ECAC512EAF Date: Tue, 8 Dec 1992 11:45:51 PST From: Russ_Housley.McLean_CSD@xerox.com Subject: IPSP Alternatives To: ipsec@ans.net Message-Id: <" 8-Dec-92 14:45:47".*.Russ_Housley.McLean_CSD@Xerox.com> IPSECers: I understand that IPSEC intends to develop a cryptographic security protocol in the Network Layer to protect client protocols of IP. The protocol formats for the IPSP will be independent of cryptographic algorithms. Host-to-host security will be addressed first, them subnet-to-subnet and host-to-subnet security will be addressed. I see three likely alternatives for IPSP. Alternative 1: Network Layer Security Protocol (NLSP) This alternative adopts the connectionless form of ISO NLSP with minimal changes. This technique will probably be compatible with the current IP and the revised IP (IP version 7). Basically two changes are being considered. The first change is clearly mandatory for the Internet protocols to work; the second change is needed to support super-encryption in some network topologies. First, NLSP needs a protocol field to carry the next-protocol identifier. The next-protocol field in IP will indicate that NLSP is above IP, and the new field in NLSP will indicate which protocol is above NLSP. This is the traditional demultiplexing technique used in Internet protocols. Second, NLSP does not permit NLSP to run over itself in all possible network topologies. In particular, NLSP cannot be implemented at both hosts and routers, such that the routers super-encrypt the host encrypted traffic, unless some other network protocol runs between the two instantiations of NLSP. Alternative 2: A Convergence Protocol for NLSP This alternative leaves NLSP unchanged, but defines a convergence protocol to carry the next-protocol identifier. This technique will probably be compatible with the current IP and the revised IP (IP version 7). One advantage with this approach is that the same convergence protocol would work with the ISO Transport layer Security Protocol (TLSP). This approach does not address super-encryption in all network topologies, but assumes that ISO will make the necessary adjustments to NLSP to resolve this problem. Alternative 3: Customized IP Security Protocol This alternative does not use any ISO defined protocol. Instead, IPSP is designed specifically for IP. The lessons from SP3 and NLSP will be used to avoid some of the same pitfalls. With this approach, the resulting IPSP may not be compatible with the revised IP (IP version 7). In order to speed IPSP developemnt, I would like to start a discussion of the pros and cons of each alternative. Russ From Paul_Lambert@poncho.phx.sectel.mot.com Tue Dec 8 07:29:52 1992 Received: from interlock.ans.net by nis.ans.net with SMTP id AA13897 (5.65c/IDA-1.4.4 for ); Tue, 8 Dec 1992 16:25:24 -0500 Received: from motgate.mot.com by interlock.ans.net with SMTP id AA25018 (InterLock SMTP Gateway 1.1 for ); Tue, 8 Dec 1992 16:24:41 -0500 Received: from pobox.mot.com ([129.188.137.100]) by motgate.mot.com with SMTP (5.65c/IDA-1.4.4/MOT-2.6 for ) id AA13712; Tue, 8 Dec 1992 15:25:07 -0600 Received: from phx.sectel.mot.com ([192.94.147.2]) by pobox.mot.com with SMTP (5.65c/IDA-1.4.4/MOT-2.6 for ) id AA13008; Tue, 8 Dec 1992 15:25:03 -0600 Received: from poncho.phx.sectel.mot.com by phx.sectel.mot.com (4.1/SMI-4.1) id AA10315; Tue, 8 Dec 92 14:21:55 MST Received: from SECTEL (QM 2.5.1) by poncho.phx.sectel.mot.com (SMTP\QM 1.1.3) id AA29705; Tue, 8 Dec 1992 14:31:33 MST Message-Id: <00112.2806669893.29705@poncho.phx.sectel.mot.com> X-Charset: MACINTOSH To: dee@skidrow.ljo.dec.com (dee), ipsec@ans.net (ip security mailing list) From: Paul_Lambert@poncho.phx.sectel.mot.com (Paul Lambert) Date: Tue, 8 Dec 1992 14:29:52 MST Subject: Re: >>FWD- Re- FYI IPSEC WG Reply to: RE>>>FWD- Re- FYI IPSEC WG C >If the current charter is interpreted broadly, and this "application >level" key management protocol can be interpreted to allow >consideration of DNS retrieval of public keys or agreement via a new >protocol number (or with new ICMPs) to either use manual key >distribution or securely exchange sessions keys and the like, then I >guess I can live with the charter. This means I assume that I can >submit a proposal which includes the possibility of host A sending a >datagram to host B which is marked as authenticated using a public key >retrievable from the DNS and the proposal will not be rejected merely >on the grounds that it is outside the charter. > >Donald Our charter is open for broad interpretation, but our schedule is quite tight. If your key management proposals are rejected it will be for technical reasons and not because of the charter. Your text above seems to imply several distinct approaches. Our goal is to define a single key management protocol to support the IPSP. While I have argued in previous postings to keep key management in the IPSEC charter, this does not mean that we will be able to define the ultimate key management protocol to meet every personUs whim. As previously suggested on this mail list, if we identify a need for such a protocol, it would belong in a new working group. The relationship between the ipsec mechanisms (key management and IPSP) and the DNS needs to be examined very closely. Your proposal to use public keys retrievable from the DNS represents just one of several ways that this information could be distributed. If we are to compare these proposals we need to start with some basic requirements and criteria for key management. Paul From ho@cs.arizona.edu Tue Dec 8 08:52:58 1992 Received: from interlock.ans.net by nis.ans.net with SMTP id AA18907 (5.65c/IDA-1.4.4 for ); Tue, 8 Dec 1992 17:53:03 -0500 Received: from optima.cs.arizona.edu by interlock.ans.net with SMTP id AA25035 (InterLock SMTP Gateway 1.1 for ); Tue, 8 Dec 1992 17:52:33 -0500 Received: from umbra.cs.arizona.edu by optima.cs.arizona.edu (5.65c/15) via SMTP id AA13201; Tue, 8 Dec 1992 15:53:00 MST Date: Tue, 8 Dec 1992 15:52:58 MST From: "Hilarie Orman" Message-Id: <199212082252.AA11630@umbra.cs.arizona.edu> Received: by umbra.cs.arizona.edu; Tue, 8 Dec 1992 15:52:58 MST To: Paul_Lambert@poncho.phx.sectel.mot.com Cc: ipsec@ans.net In-Reply-To: Your message <00112.2806669893.29705@poncho.phx.sectel.mot.com> Subject: Re: FYI IPSEC WG Why has the schedule been set tight? Is this because of pressing needs, or because of experiences that indicate a protocol is either done quickly or not at all? I can understand a desire to have at least one key management protocol that will support IPSP near-term, but it is does seem odd to require that the definition of IPSP itself do anything more than specify the interface to the key management protocol layer. Perhaps someone will argue that if there is algorithm selection and/or negotiation, then it will become too complicated to assure that security is provided, and therefore only one algorithm will be allowed. But the discussion has left me a little confused about the actual motivations. From dee@skidrow.pa.dec.com Wed Dec 9 09:51:45 1992 Received: from interlock.ans.net by nis.ans.net with SMTP id AA40367 (5.65c/IDA-1.4.4 for ); Wed, 9 Dec 1992 15:02:52 -0500 Received: from inet-gw-1.pa.dec.com by interlock.ans.net with SMTP id AA34160 (InterLock SMTP Gateway 1.1 for ); Wed, 9 Dec 1992 14:51:40 -0500 Received: by inet-gw-1.pa.dec.com; id AA08297; Wed, 9 Dec 92 11:52:00 -0800 Received: by skidrow.ljo.dec.com (5.57/Ultrix3.0-C) id AA18969; Wed, 9 Dec 92 14:51:45 -0500 Message-Id: <9212091951.AA18969@skidrow.ljo.dec.com> Reply-To: dee@skidrow.ljo.dec.com To: Paul_Lambert@poncho.phx.sectel.mot.com (Paul Lambert) Cc: ipsec@ans.net (ip security mailing list) Subject: Re: >>FWD- Re- FYI IPSEC WG In-Reply-To: Your message of "Tue, 08 Dec 92 14:29:52 MST." <00112.2806669895.29706@poncho.phx.sectel.mot.com> Date: Wed, 09 Dec 92 14:51:45 -0500 From: "Beast (Donald E. Eastlake, 3rd)" X-Mts: smtp From: Paul_Lambert@poncho.phx.sectel.mot.com (Paul Lambert) To: dee@skidrow.ljo.dec.com (dee), ipsec@ans.net (ip security mailing list) >>If the current charter is interpreted broadly, and this "application >>level" key management protocol can be interpreted to allow >>consideration of DNS retrieval of public keys or agreement via a new >>protocol number (or with new ICMPs) to either use manual key >>distribution or securely exchange sessions keys and the like, then I >>guess I can live with the charter. This means I assume that I can >>submit a proposal which includes the possibility of host A sending a >>datagram to host B which is marked as authenticated using a public key >>retrievable from the DNS and the proposal will not be rejected merely >>on the grounds that it is outside the charter. >>Donald > >Our charter is open for broad interpretation, but our schedule is quite >tight. If your key management proposals are rejected it will be for >technical reasons and not because of the charter. Your text above seems to >imply several distinct approaches. Our goal is to define a single key >management protocol to support the IPSP. I gather then that the answer to my question is yes. I really meant DNS key retrieval to be an example of the type of thing that I did not want ruled out by the words "application level key management protocol". My understanding is that the "key managmenet protocol" is already assumed to include some way to say that the parties should use manually distributed keys as well as some second type of agreement, such as certificates. So two possibilities are already encompassed. >While I have argued in previous postings to keep key management in the IPSEC >charter, this does not mean that we will be able to define the ultimate key >management protocol to meet every personUs whim. As previously suggested on [trivial aside: you really should use some software that translates Macintosh characters to equivalent USASCII or something...] >this mail list, if we identify a need for such a protocol, it would belong >in a new working group. I would urge the strong resistence of any attempt to define "the ultimate" anything, in this working group or any other. The success of the Internet has to a great extent come from focusing efforts on getting something simple working in a timely fashion to meet most needs. I think the IPSP should be grounded in the real requirements, current and anticipated, of the Internet and not based on anyone's whim nor be a copy of an OSI protocol just because the OSI protocol is an OSI standard. It seems to me that there are needs in the Internet for efficient secure "connections" at the IP level as well as for at least authenticated isolated datagrams. While I think the secured datagram formats could be identical for these two cases, the key management requirments are different. >The relationship between the ipsec mechanisms (key management and IPSP) and >the DNS needs to be examined very closely. Your proposal to use public keys Why does the relationship with DNS need to be examined more carefully than other aspecst of IPSP? It sounds a bit like you are just setting things up, even at this early stage, to say that anything other than a NLSP clone with key certificates needs further study and should be pushed aside. >retrievable from the DNS represents just one of several ways that this >information could be distributed. If we are to compare these proposals we >need to start with some basic requirements and criteria for key management. Sounds like a good idea. >Paul Donald From Paul_Lambert@poncho.phx.sectel.mot.com Wed Dec 9 10:23:46 1992 Received: from interlock.ans.net by nis.ans.net with SMTP id AA27221 (5.65c/IDA-1.4.4 for ); Wed, 9 Dec 1992 19:32:05 -0500 Received: from motgate.mot.com by interlock.ans.net with SMTP id AA32460 (InterLock SMTP Gateway 1.1 for ); Wed, 9 Dec 1992 19:21:44 -0500 Received: from pobox.mot.com ([129.188.137.100]) by motgate.mot.com with SMTP (5.65c/IDA-1.4.4/MOT-2.6 for ) id AA28571; Wed, 9 Dec 1992 18:22:10 -0600 Received: from phx.sectel.mot.com ([192.94.147.2]) by pobox.mot.com with SMTP (5.65c/IDA-1.4.4/MOT-2.6 for ) id AA19274; Wed, 9 Dec 1992 18:22:07 -0600 Received: from poncho.phx.sectel.mot.com by phx.sectel.mot.com (4.1/SMI-4.1) id AA13913; Wed, 9 Dec 92 17:18:53 MST Received: from SECTEL (QM 2.5.1) by poncho.phx.sectel.mot.com (SMTP\QM 1.1.3) id AA29776; Wed, 9 Dec 1992 17:28:40 MST Message-Id: <00112.2806766920.29776@poncho.phx.sectel.mot.com> X-Charset: MACINTOSH To: ho@cs.arizona.edu (Hilarie Orman), ipsec@ans.net (ip security mailing list) From: Paul_Lambert@poncho.phx.sectel.mot.com (Paul Lambert) Date: Wed, 9 Dec 1992 17:23:46 MST Subject: foot extraction Subject: foot extraction Message: Hilarie, In reading the comments that I posted I can understand your confusion. >Why has the schedule been set tight? Is this because of pressing >needs, or because of experiences that indicate a protocol is either >done quickly or not at all? I can understand a desire to have at >least one key management protocol that will support IPSP near-term, >but it is does seem odd to require that the definition of IPSP itself >do anything more than specify the interface to the key management >protocol layer. Perhaps someone will argue that if there is algorithm >selection and/or negotiation, then it will become too complicated to >assure that security is provided, and therefore only one algorithm >will be allowed. But the discussion has left me a little confused >about the actual motivations. I will attempt to take my foot out of my mouth/terminal ...... We set a goal in the charter is to have a draft specification for ipsec key management delivered in July of 1993. The main motivation was to deliver the key management shortly after the basic IPSP. This allowed the documentation of subnet-to-subnet services to be worked together with the key management. It was assumed that some of the sub-net issues and key management were inherently linked. Independant of the schedule we need to have a focused set of goals / requirements for ipsec key management. Paul PS - A router upstream from my office was configured wrong for two days (Monday afternoon till now) so I've missed all mail sent directly to my address during this period. From dee@skidrow.pa.dec.com Thu Dec 10 07:17:09 1992 Received: from interlock.ans.net by nis.ans.net with SMTP id AA34377 (5.65c/IDA-1.4.4 for ); Thu, 10 Dec 1992 12:29:58 -0500 Received: from inet-gw-1.pa.dec.com by interlock.ans.net with SMTP id AA16041 (InterLock SMTP Gateway 1.1 for ); Thu, 10 Dec 1992 12:15:50 -0500 Received: by inet-gw-1.pa.dec.com; id AA28075; Thu, 10 Dec 92 09:16:18 -0800 Received: by skidrow.ljo.dec.com (5.57/Ultrix3.0-C) id AA20948; Thu, 10 Dec 92 12:17:10 -0500 Message-Id: <9212101717.AA20948@skidrow.ljo.dec.com> Reply-To: dee@skidrow.ljo.dec.com To: kent@bbn.com Cc: ipsec@ans.net Subject: Re: FWD: Re: Encapsulation vs options In-Reply-To: Your message of "Mon, 07 Dec 92 17:13:07 EST." Date: Thu, 10 Dec 92 12:17:09 -0500 From: "Beast (Donald E. Eastlake, 3rd)" X-Mts: smtp >From: US1RMC::"kent@BBN.COM" "Steve Kent" 7-DEC-1992 16:51 >Subj: Re: Encapsulation vs options > >Donald, > I've worked on the development of encapsulating, network and >transport layer cryptographic protocols off and on for the last 14 >years. ... Steve, I'm sure that you and and others on this list are more knowledgeable and experienced than I am. That's one reason that I feel I can present new ideas and suggest changes with confidence that I will be corrected if I'm off base. >... If we place such protocols in routers, so that they can >protect whole subnets, then it is helpful to be able to direct packets >to a specific router when more than one router serves a subnet >(multi-homed subnet). This removes some of the functionality provided >by IP in terms of quick response to a failed router, but it simplifies >key management among the routers. That is a large part of the >motivation. Also, should an encrypted packet be fragmented by a >(non-crypto) router, it helps to have all of the fragments come >together at the same crypto-router. That is easily achieved if the >packets are addressed (using an outer IP address via encapsulation) to >a crypto-router vs. the true endpoint (behind the crypto-router). I'm not sure how much detail to go into this if host-to-host security is going to be tackled first; however, I think I understand why you would want to provide security at the subnet level, to, for example, avoid the burden and possible administrative problems in having security software and keys floating around on lots of single user desk-top machines. So lets say I have hosts 01 through 99 that are hooked to the outside work through routers A, B, C, D, and E. I think I also understand why it would be convenient to have crypto stuff concentrated into one of these routers, say C. This makes some things simpler, including fragment re-assembly (which I had not though enough about). However, it seems like it makes other things harder. How does host 17 know that it needs to send outgoing traffic through C? In fact, in the general production/ubiquitous-security case, the crypto traffic from the various hosts has to be spread over these multiple routers so how are the true network level source/destination pairs (before encapsulation) associated with routers? If you just use general routing, what happens when that changes? How do all the routers know to direct incoming traffic purporting to relate to a particular ultimate source/destination address pair to router C (or the appropriate router in the general case)? If they don't, can't someone just forge the plain text packets that C send to host 17 and spoof things if their traffic happens to be routed via A, B, D, or E? > Fragmentation also provides a motivation for an encapsulating >security protocol when the protocol is implemented at routers. An IP >datagram may be fragmented prior to encryption and after encryption, >and it is essential to know which fragments are which (pre vs. post >encryption). So, an encapsulating network layer security protocol >facilitates resolution of this problem as well. This is a good argument for encapsulation at the subnet level. I don't see this as an argument against an option at the host level other than that, obviously, having both encapsulation and an option is more complex than having only one mechanism. However, as I pointed out in one earlier message, you could use IP in IP encapsulation with a security option at each level, not that I claimed this was particularly attractive. >Steve Donald From dee@skidrow.pa.dec.com Thu Dec 10 07:44:08 1992 Received: from interlock.ans.net by nis.ans.net with SMTP id AA27492 (5.65c/IDA-1.4.4 for ); Thu, 10 Dec 1992 12:56:14 -0500 Received: from inet-gw-1.pa.dec.com by interlock.ans.net with SMTP id AA15954 (InterLock SMTP Gateway 1.1 for ); Thu, 10 Dec 1992 12:42:49 -0500 Received: by inet-gw-1.pa.dec.com; id AA29447; Thu, 10 Dec 92 09:43:16 -0800 Received: by skidrow.ljo.dec.com (5.57/Ultrix3.0-C) id AA21029; Thu, 10 Dec 92 12:44:09 -0500 Message-Id: <9212101744.AA21029@skidrow.ljo.dec.com> Reply-To: dee@skidrow.ljo.dec.com To: Russ_Housley.McLean_CSD@xerox.com Cc: ipsec@ans.net Subject: Re: FWD: IPSP Alternatives In-Reply-To: Your message of "Tue, 08 Dec 92 16:37:11 EST." Date: Thu, 10 Dec 92 12:44:08 -0500 From: "Beast (Donald E. Eastlake, 3rd)" X-Mts: smtp Russ, I'm sorry to say that, for the reasons given below, I don't accept your analysis into three alternatives. >From: US1RMC::"Russ_Housley.McLean_CSD@xerox.com" 8-DEC-1992 16:29 >To: ipsec@ans.net >Subj: IPSP Alternatives > >IPSECers: > >[repeat of stuff from draft charter] > >I see three likely alternatives for IPSP. > >Alternative 1: Network Layer Security Protocol (NLSP) > >This alternative adopts the connectionless form of ISO NLSP with minimal >changes. This technique will probably be compatible with the current IP and >the revised IP (IP version 7). Basically two changes are being considered. >The first change is clearly mandatory for the Internet protocols to work; the >second change is needed to support super-encryption in some network >topologies. > >First, NLSP needs a protocol field to carry the next-protocol identifier. The >next-protocol field in IP will indicate that NLSP is above IP, and the new >field in NLSP will indicate which protocol is above NLSP. This is the >traditional demultiplexing technique used in Internet protocols. > >Second, NLSP does not permit NLSP to run over itself in all possible network >topologies. In particular, NLSP cannot be implemented at both hosts and >routers, such that the routers super-encrypt the host encrypted traffic, unles s >some other network protocol runs between the two instantiations of NLSP. > >Alternative 2: A Convergence Protocol for NLSP > >This alternative leaves NLSP unchanged, but defines a convergence protocol to >carry the next-protocol identifier. This technique will probably be compatibl e >with the current IP and the revised IP (IP version 7). One advantage with thi s >approach is that the same convergence protocol would work with the ISO >Transport layer Security Protocol (TLSP). This approach does not address >super-encryption in all network topologies, but assumes that ISO will make the >necessary adjustments to NLSP to resolve this problem. I'd like to know, from practical point of view, what the real difference between the above alternatives is. I'm sure you will correct me if I'm wrong, but I don't see any. In one case you add a field to NLSP for the next protocol and declare that it can be nested. In the second case, you add a field to NLSP, except that you give it a much more complicated sounding label ("convergence protocol") and for some reason that baffles me completely, you fail to declare that it can be nested but instead claim some need to wait on the ISO process. (And why do you belive that ISO will do it at all let alone within the schedule this WG adopts?) >Alternative 3: Customized IP Security Protocol > >This alternative does not use any ISO defined protocol. Instead, IPSP is >designed specifically for IP. The lessons from SP3 and NLSP will be used to >avoid some of the same pitfalls. With this approach, the resulting IPSP may >not be compatible with the revised IP (IP version 7). Both alternatives 1 and 2 above, if you want to consider them different, took an ISO protocol and modified/augmented it. I can't understand why some change makes them still be ISO protocols somehow likely to work with IPv7 while being a little further from NLSP makes something not an ISO protocol suddenly subject to the spectre of not working with IPv7. Unless you could plug them into each other (in some logical sense) and have them interoperate, they are not the same protocol. Thus it seems clear that the output of this WG will not be any ISO defined protocol, no matter what, although parts of it, such as key certificate formats, could conform to an ISO standard. Perhaps for Alternative 3 you meant "Customized *IPv4* Security Protocol". If so, you need to either broaden the alternative or add a 4th alternative. It seems to me to be pretty pointless to try to evaluate this alternative without a concrete proposal. Perhaps I will try to come up with one. >In order to speed IPSP developemnt, I would like to start a discussion of the >pros and cons of each alternative. >Russ Donald From dee@skidrow.pa.dec.com Tue Dec 15 10:19:56 1992 Received: from interlock.ans.net by nis.ans.net with SMTP id AA47691 (5.65c/IDA-1.4.4 for ); Tue, 15 Dec 1992 15:33:24 -0500 Received: from inet-gw-1.pa.dec.com by interlock.ans.net with SMTP id AA29331 (InterLock SMTP Gateway 1.1 for ); Tue, 15 Dec 1992 15:18:28 -0500 Received: by inet-gw-1.pa.dec.com; id AA06789; Tue, 15 Dec 92 12:18:56 -0800 Received: by skidrow.ljo.dec.com (5.57/Ultrix3.0-C) id AA01122; Tue, 15 Dec 92 15:19:56 -0500 Message-Id: <9212152019.AA01122@skidrow.ljo.dec.com> Reply-To: dee@skidrow.ljo.dec.com To: Steve Kent Cc: ipsec@ans.net Subject: Re: FWD: Re: Encapsulation vs options In-Reply-To: Your message of "Thu, 10 Dec 92 22:00:01 EST." <9212111948.AA03100@inet-gw-1.pa.dec.com> Date: Tue, 15 Dec 92 15:19:56 -0500 From: "Beast (Donald E. Eastlake, 3rd)" X-Mts: smtp From: Steve Kent To: dee@skidrow.ljo.dec.com In-Reply-To: Your message of Thu, 10 Dec 92 12:17:09 -0500. <9212101717.AA20948@skidrow.ljo.dec.com> >Donald, > In situations where a network layer security protocol is >provided at routers, the common model is that it is provided at ALL >the routers to a campus net or LAN. Thus there is not a problem of >directing traffic to the 1 router in three which has the crypto. That's what I would have thought. However, your first message in this sequence contained the following sentence: "The use of encapsulation makes it easier to direct packets to a particular router (where the crypto capability is located)." This gave me the impression that only one router was crypto capable. That lead to my series of questions about the complexities this would cause if there were other non-crypto routers. >Steve Donald From kent@BBN.COM Mon Dec 14 06:05:46 1992 Received: from interlock.ans.net by nis.ans.net with SMTP id AA13493 (5.65c/IDA-1.4.4 for ); Wed, 16 Dec 1992 11:52:51 -0500 Received: from CCV1.BBN.COM by interlock.ans.net with SMTP id AA37215 (InterLock SMTP Gateway 1.1 for ); Wed, 16 Dec 1992 11:51:12 -0500 Message-Id: <199212161651.AA37215@interlock.ans.net> To: ipsec@ans.net Subject: mail list problem? Date: Mon, 14 Dec 92 11:05:46 -0500 From: Steve Kent ------- Forwarded Message Date: Mon, 14 Dec 92 1:15:01 EST From: BBN Mail System (MMDF) Sender: mmdf@BBN Subject: Failed mail (msg.aa19746) To: kent@bbn.com After 4 days (75 hours), your message could not be fully delivered. It failed to be received by the following address(es): ipsec@ans.net (host: ans.net) (queue: smtp) Problems usually are due to service interruptions at the receiving machine. Less often, they are caused by the communication system. Your message follows: To: dee@skidrow.ljo.dec.com cc: ipsec@ans.net Subject: Re: FWD: Re: Encapsulation vs options In-reply-to: Your message of Thu, 10 Dec 92 12:17:09 -0500. <9212101717.AA20948@skidrow.ljo.dec.com> Date: Thu, 10 Dec 92 22:00:01 -0500 From: Steve Kent Donald, In situations where a network layer security protocol is provided at routers, the common model is that it is provided at ALL the routers to a campus net or LAN. Thus there is not a problem of directing traffic to the 1 router in three which has the crypto. The fragmentation problems are well addressed with an encapsulation protocol, but not by just an IP option. I expect that a combination of the two, IP encapsulation plus an option, could achieve the same effect. The other concern about IP options is the one mentioned previously, i.e., there isn't much room available for options and this might be very constraining on the protocol. Steve ------- End of Forwarded Message From kent@BBN.COM Wed Dec 16 05:17:47 1992 Received: from interlock.ans.net by nis.ans.net with SMTP id AA21508 (5.65c/IDA-1.4.4 for ); Wed, 16 Dec 1992 11:56:41 -0500 Received: from CCV1.BBN.COM by interlock.ans.net with SMTP id AA29026 (InterLock SMTP Gateway 1.1 for ); Wed, 16 Dec 1992 11:52:14 -0500 Message-Id: <199212161652.AA29026@interlock.ans.net> To: dee@skidrow.ljo.dec.com Cc: ipsec@ans.net Subject: Re: FWD: Re: Encapsulation vs options In-Reply-To: Your message of Tue, 15 Dec 92 15:19:56 -0500. <9212152019.AA01122@skidrow.ljo.dec.com> Date: Wed, 16 Dec 92 10:17:47 -0500 From: Steve Kent Donald, The motive for directing packets to a particular router arises on the "black" (ciphertext) side, to address black side fragmentation. This concern prompted me to cite that feature of encapsulation. Steve