From owner-ipsec Fri Jan 2 23:09:03 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id XAA17981 for ipsec-outgoing; Fri, 2 Jan 1998 23:00:29 -0500 (EST) Date: Sat, 3 Jan 1998 06:11:22 +0200 (EET) Message-Id: <199801030411.GAA11278@pilari.ssh.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Tero Kivinen To: anx-sec@dot.netrex.net, ipsec@tis.com Reply-To: ipsec@tis.com Subject: SSH ISAKMP/Oakley interoprability test site announcement X-Mailer: VM 6.34 under Emacs 19.34.2 Organization: SSH Communications Security Oy X-Edit-Time: 3 min Sender: owner-ipsec@ex.tis.com Precedence: bulk The SSH ISAKMP/Oakley test site is now available for testing. See: . This site was already announced in the Washington IETF IPSec session, and has been operational since then, but this is official announcement for its availability for testing. The SSH ISAKMP/Oakley test site is web based test site for ISAKMP/Oakley servers and it allows your implementation to perform negotiations against the test server. It gives you sufficient debugging output, so you can resolve most problems yourself; we are happy to work with you on the remaining ones (send mail to isakmp-support@ssh.fi). For demonstration purposes, you can also put our implementation negotiating against itself by giving 194.100.55.1 as the IP address for the other end and using different port number for each end. I've now configured the system so that you can also use port 500 for testing at the SSH end. So if you couldn't test earlier because you couldn't configure the remote port, now you can also use port 500. Because only one user can be testing in the same port at same time (the test servers are each completely separate from each other, but running on same machine), it would be good to use some other port if you can, and leave port 500 for those who cannot choose... The SSH ISAKMP/Oakley test site supports latest drafts (isakmp-08+ (certificate request payload is already changed to newer format coming in next version of draft), oakley-02, isakmp-oakley-05, doi-06), and following options in those drafts: - Several compatibility flags (including "Only IP number in HASH", "Old Public key encryption PRF key", and "Old certificate request payload format"). - Authentication with Pre-Shared keys and limited support for DSA/RSA signatures and RSA encryption authentications. Authentication via signatures or encryption is slightly limited because you have to configure your own system so it trusts our test CA key (certificate for it can be found on the main page) or just trusts any certificate sent by the other end (you also need to put the "trust all certificates" flag on in SSH end so it will trust your certificates). The certificate sent by the other end must have the correct IP address in the alt name field. We can also manually do some CA operations here, so send mail to isakmp-support@ssh.fi if you want to do even more complicated certificate testing. - Both responder and initiator ends. - Both Main mode and Aggressive mode. - New group mode between main or aggressive mode and quick mode. - Quick mode. - Encryption algorithms: DES, Blowfish, 3DES, and CAST-128. - Hash algorithms: MD5, and SHA - Diffie-Hellman Groups: 1, 2, private group arguments given in ISAKMP proposal, and private group negotiated in new group mode (for quick mode). - With or without PFS in quick mode. The ISAKMP/Oakley test site is NOT connected to an IPSec engine so it will just print out the resulting keys after negotiation, so you can check them (note, that it will print just raw key material, parity bits etc are fixed in the IPSec engine level, not in this level). If you have any comments, problems, enchancements etc please send mail to isakmp-support@ssh.fi. I will try to add some more help texts to the pages later, but I think implementators should be able to understand the user interface and debug output already. I really hope this service will be usefull to IPSec community. -- kivinen@ssh.fi Work : +358-9-4354 3207 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec.html From owner-ipsec Mon Jan 5 07:51:04 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA04637 for ipsec-outgoing; Mon, 5 Jan 1998 07:41:28 -0500 (EST) Date: Sun, 4 Jan 1998 12:16:01 -0800 (PST) From: Tom Henderson Reply-To: tomh@cs.berkeley.edu To: ipsec@tis.com cc: tomh@cs.berkeley.edu Subject: IPSEC and TCP headers Message-ID: Organization: UC Berkeley Computer Science X-Url: http://www.cs.berkeley.edu/~tomh MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk Has the IPSEC group ever considered a variation to the transport mode which, if TCP were being used on a flow, would leave the TCP header unencrypted and unauthenticated? If TCP were not being used, the normal transport mode would be used; e.g.: BEFORE APPLYING ESP ---------------------------------- IPv4 |orig IP hdr | TCP | TCP | |(any options)| header | payload | ---------------------------------- AFTER APPLYING ESP -------------------------------------------------------------- IPv4 |orig IP hdr | Orig TCP hdr) | ESP | TCP | ESP | ESP| |(any options)| (any options) | Hdr | payload | Trailer |Auth| -------------------------------------------------------------- |<-- encrypted ---->| |<----- authenticated --->| Such an approach would allow various strategies aimed at improving TCP performance over challenging network segments (e.g., TCP snoop) to be deployed in a transit network, particularly wireless networks. While such an approach might leave flows vulnerable to malicious TCP spoofing, if additional security measures were adopted by the wireless network to eliminate unauthorized spoofing, this method would be useful. Has the group considered this approach before (I could not find discussion of it on the list archive or the internet drafts)? Thanks, Tom Henderson EECS Dept., UC Berkeley tomh@cs.berkeley.edu From owner-ipsec Mon Jan 5 08:16:47 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA05080 for ipsec-outgoing; Mon, 5 Jan 1998 08:16:25 -0500 (EST) Message-Id: <199801051325.IAA23182@postal.research.att.com> To: tomh@cs.berkeley.edu cc: ipsec@tis.com Subject: Re: IPSEC and TCP headers Date: Mon, 05 Jan 1998 08:25:46 -0500 From: Steve Bellovin Sender: owner-ipsec@ex.tis.com Precedence: bulk Such an approach would allow various strategies aimed at improving TCP performance over challenging network segments (e.g., TCP snoop) to be deployed in a transit network, particularly wireless networks. While such an approach might leave flows vulnerable to malicious TCP spoofing, if additional security measures were adopted by the wireless network to eliminate unauthorized spoofing, this method would be useful. Has the group considered this approach before (I could not find discussion of it on the list archive or the internet drafts)? As you note, there are security risks from doing so. Moreover, there are other protocols, notably TLS (aka SSL) that do what you want. I personally don't see the need for an IPSEC variant that would compete with TLS. From owner-ipsec Mon Jan 5 09:15:42 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA05518 for ipsec-outgoing; Mon, 5 Jan 1998 09:14:34 -0500 (EST) Message-Id: <3.0.5.32.19980105092429.00add3f0@pop3hub.is.chrysler.com> X-Sender: rgm3@pop3hub.is.chrysler.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 05 Jan 1998 09:24:29 -0500 To: ben@Ascend.COM (Ben Rogers), ipsec@tis.com From: Robert Moskowitz Subject: Re: Results of the IPSEC document reading party In-Reply-To: <199712232339.SAA25495@carp.morningstar.com> References: <199712192001.PAA25375@dcl.MIT.EDU> <199712192001.PAA25375@dcl.MIT.EDU> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 06:39 PM 12/23/97 -0500, Ben Rogers wrote: > >Sorry to jump into this particular conversation a bit belatedly, but I >was waiting on a response from Bob to an issue I had wanted resolved >before bringing this to the group. But, he's evidently too busy to >respond, so here we go: No, just on vacation and my wife had very strong opinions on what we would be spending our time on. I am back in now and trying to make sense of the discussion. Just wanted to let people know that I did in fact fall off the discussion for a number of days and now have lots of mail to go through.... Robert Moskowitz Chrysler Corporation (810) 758-8212 From owner-ipsec Mon Jan 5 09:39:40 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA05714 for ipsec-outgoing; Mon, 5 Jan 1998 09:37:27 -0500 (EST) From: hsw@columbia.sparta.com (Howard Weiss) Message-Id: <9801051448.AA03479@katahdin.columbia.sparta.com> Subject: Re: IPSEC and TCP headers To: tomh@cs.berkeley.edu Date: Mon, 5 Jan 1998 09:48:25 -0500 (EST) Cc: ipsec@tis.com In-Reply-To: from "Tom Henderson" at Jan 4, 98 12:16:01 pm Organization: SPARTA Inc. (Secure Systems Engineering Division) Usmail: 9861 Broken Land Parkway, Suite 300, Columbia MD 21046 Phone: (410) 381-9400 x201 Fax: (410) 381-5559 X-Mailer: ELM [version 2.4PL24 PGP3 ALPHA] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Have you looked at TLS? -- ___________________________________________________________________ | | |Howard Weiss phone (410) 381-9400 x201 | |SPARTA, Inc. (301) 621-8145 x201 (DC) | |9861 Broken Land Parkway, suite 300 fax: (410) 381-5559 | |Columbia, MD 21046 email: hsw@columbia.sparta.com | |___________________________________________________________________| From owner-ipsec Mon Jan 5 18:05:57 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA09152 for ipsec-outgoing; Mon, 5 Jan 1998 18:03:36 -0500 (EST) From: svakil@usr.com Mime-Version: 1.0 Date: Mon, 5 Jan 1998 16:55:54 -0600 Message-ID: <4B1E11E0.3000@usr.com> Subject: ANX bakeoff info To: ipsec@tis.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Sender: owner-ipsec@ex.tis.com Precedence: bulk Where can I get information like the schedules, sign up procedures, etc. for the ANX IPSec interoperability workshops? Thanks, Sumit A. Vakil Software Engineer Tunneling and Security Group 3Com, Corporation From owner-ipsec Wed Jan 7 16:00:57 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA25813 for ipsec-outgoing; Wed, 7 Jan 1998 15:48:43 -0500 (EST) From: Dan McDonald Message-Id: <199801072101.NAA19106@kebe.eng.sun.com> Subject: Corner case: Replay and INADDR_ANY src addressed SAs To: ipsec@tis.com Date: Wed, 7 Jan 1998 13:01:08 -0800 (PST) X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Hello! I've found an interesting corner case that's almost-but-not-quite nailed in the specs. Consider an SA with a source address of INADDR_ANY (or IN6ADDR_ANY for IPv6 fans in the audience). Since SAs are keyed off of , the source address can be unspecified. The normal usage for such SAs are multicast and (gag) broadcast. It is possible, however, to have an SA with an unspecified source address and a unicast destination. The spec says that replay protection should be disabled for multicast SAs. What about unicast SAs that have multiple senders? Likewise, if a multicast SA only has one sender, replay protection should be able to work alright. Yes it's a corner case, but it's looking like the smart thing to do is check replay: a.) If enabled on the SA and b.) Integrity is enabled (always true for AH, sometimes true for ESP) and c.) If there's a _specific_ source address tied to the SA Am I missing something here? -- Daniel L. McDonald - Solaris Internet Engineering || MY OPINIONS ARE NOT Mail: danmcd@eng.sun.com, danmcd@kebe.com <*> || NOT NECESSARILY SUN'S! Phone: (650) 786-6815 |"rising falling at force ten WWW: http://www.kebe.com/~danmcd | we twist the world and ride the wind" - Rush From owner-ipsec Wed Jan 7 20:13:31 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA27265 for ipsec-outgoing; Wed, 7 Jan 1998 20:12:10 -0500 (EST) Message-ID: <34B42A33.43C7E525@tiac.net> Date: Wed, 07 Jan 1998 20:21:55 -0500 From: Michael Giniger X-Mailer: Mozilla 4.01 [en] (Win95; I) MIME-Version: 1.0 To: ipsec@tis.com Subject: implicit padding for authentication X-Priority: 3 (Normal) Content-Type: text/plain; charset=iso-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by mail-out-3.tiac.net id UAA13221 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by portal.ex.tis.com id UAA27262 Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi I have been reviewing the AH and ESP drafts and I was wondering if someone could clarify the use of implicit packet padding. draft-ietf-ipsec-auth-header-03.txt sec. 3.3.3.2.2 entitled "implicit packet padding" says that "…If the IP packet length (including AH) does not match the blocksize requirements for the algorithm, implicit padding MUST be appended to the end of the packet, prior to ICV computation. The padding octets MUST have a value of zero. The blocksize (and hence the length of the padding) is specified by the alogirthm specification. This padding is not transmitted with the packet draft-ietf-ipsec-v2-02.txt in sec. 3.3.4 entitled "Integrity Check Value Calculation" has similar language. RFC 1321 (MD5) and FIPS PUB 180-1 (SHA-1) specify that the message is padded so that its length in bits is congruent to 448 modulo 512 whereby the first bit is a single "1" followed by all "0" bits. Thereafter a 64-bit representation of the length of the message (in bits -- before the padding bits were added) is appended to the padding bits. I would like a clarification as to whether implicit padding is ever applied when either MD5 or SHA-1 is used as the hashing algorithm (as in draft-ietf-ipsec-auth-hmac-md5-01.txt and draft-ietf-ipsec-auth-hmac-sha1-01.txt.) It doesn't seem that implicit padding is needed since both algorithms have the same simple mechanism for padding with length to the 512-bit block size. Is this correct? If not, could you tell me when implict padding is used and what the interaction is with the specified padding of the hashing documents? Thank you very much for your help Sincerely Michael Giniger From owner-ipsec Fri Jan 9 16:56:22 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA13925 for ipsec-outgoing; Fri, 9 Jan 1998 16:43:42 -0500 (EST) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <34B42A33.43C7E525@tiac.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 9 Jan 1998 16:54:33 -0500 To: Michael Giniger From: Stephen Kent Subject: Re: implicit padding for authentication Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Mike sent this message to me earlier and I failed to respond; I agree that the WG needs to decide on this. This padding spec has been around for some time and was not revised when we made changes to the encryption padding requirements. Since the hash algorithms that underly HMAC specify their own padding, it would seem appropriate to make the padding requirement be an algorithm-specific matter and refer to the relevant algorithm document. We could spevify this as the default to be used if there is no algorithm-specific padding, but that case seems rare and it would seem to be easier to relegate this to the ICV algorithm spec in every case. However, I'd alos like to know what implementors are doing now, since testing has been ongoing for some time and people have interoperated on the basis of some common interpretation of implicit padding. Finally, let me offer one motivation to switch to algorithm-specific padding as specified in the algorithm definitions: hardware. Crypto hardware (e.g. a generic chip) that implements hashing might generate padding based on an algorithmic spec such as those for MD5 and SHA-1 and thus would cause problems if we retain the current definition. Steve From owner-ipsec Fri Jan 9 23:54:31 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id XAA16067 for ipsec-outgoing; Fri, 9 Jan 1998 23:49:38 -0500 (EST) Message-Id: <98Jan10.000206est.11657@janus.tor.securecomputing.com> To: Stephen Kent Cc: ipsec@tis.com Subject: Re: implicit padding for authentication References: In-reply-to: Your message of "Fri, 09 Jan 1998 16:54:33 -0500". From: "C. Harald Koch" X-uri: X-Face: )@F:jK?*}hv!eJ}*r*0DD"k8x1.d#i>7`ETe2;hSD2T!:Fh#wu`0pW7lO|Dfe'AbyNy[\Pw z'.bAtgTM!+iq2$yXiv4gf<:D*rZ-|f$\YQi7"D"=CG!JB?[^_7v>8Mm;z:NJ7pss)l__Cw+.>xUJ) did@Pr9 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <16053.884408489.1@tor.securecomputing.com> Date: Sat, 10 Jan 1998 00:01:30 -0500 Sender: owner-ipsec@ex.tis.com Precedence: bulk In message , Stephen Kent writes: > However, I'd also like to know what implementors are doing now, since > testing has been ongoing for some time and people have interoperated on the > basis of some common interpretation of implicit padding. Simple. Since MD5 and SHA1 define their own padding algorithms, treat them has having a block-size of 1 byte for IPsec implicit padding purposes; in other words, no implicit padding is required for these algorithms. -- Harald Koch From owner-ipsec Mon Jan 12 08:20:34 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA03130 for ipsec-outgoing; Mon, 12 Jan 1998 08:06:39 -0500 (EST) Message-Id: <199801111935.NAA06175@osgroup.com> From: "Xuechen Yang" To: , Cc: Subject: some issues about IPSec Date: Sun, 11 Jan 1998 12:34:29 -0600 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi Ken & Randall, Sorry the late comments. I like to have your opinions on some issues. Basically we already got a bump-in-the-stack implementation for Windows 95 and Windows NT working. This implementation supports multiple security channels between two hosts or host and security gateway or two security gateways. User can configure which application protocol to protect (FTP, TELNET, HTTP...) and what kind of algorithm to use. Now it only works with manual key management and only in tunnel mode. But it doesn't fully support the latest draft you wrote (Nov. 1997). It doesn't support ICMP PMTU message parsing, though it does parse ICMP redirect message. (Driver maintains its own routing table. Every tunnel point/security gateway has its own entry in this table. If no entry existed for a security gateway, after driver applied certain SAs to the outgoing IP packet, driver always sends the packet to the same network interface that the original IP packet was targeted to. If driver received an ICMP redirect message from the router, it will update the routing table according the information contained in that ICMP message. Anyway, this is just a local implementation matter, it's not my question. :) ). (1) Although we didn't intend to implement IPSec server (e.g. NT server gateway) driver as well, we had to do internal test between two hosts and they both had our IPSec drivers installed. We found out we have to let user choose host type based on per protocol: CLIENT or SERVER. For instance: assume we have two hosts A and B. We use A as a FTP server, and configure both of them to enable IPSec protection and use same encryption algorithm and authentication algorithm. If we try to FTP A from B, the IPSec implementation on B has to check the destination port number combined with destination IP address and transport type of every outgoing packet to decide whether this packet should be applied with the SA which was assigned to protect FTP channel between A and B. On the A (server) side, the IPSec implementation has to check the source port number instead of destination port number. But of course, we can simply the approach: if either destination or source port is equal to 20 or 21, driver applies the SA. But I don't think it's a good way. I thought another way and that is implied by your draft: In SPD, user has to define both source port number and destination number for every connection. Whenever user opens a socket, IPSec implementation will update SPD and use the new source port number as a selector (on client side if the destination number already existed as a selector). However, it's difficult to implement for BITS. And I think it's more natural if we only let user choose the well-known port number defined for server. On server side, that's the source port; on the client side, that's destination port. (2) Fragmentation in transport mode for BITS For the implementation of integrating IPSec into natural TCP/IP stack, fragmentation won't be an issue. But for BITS implementation, fragmentation is worth to mention in transport mode. The problem is when BITS-IPSec implementation receives an outgoing packet from TCP/IP stack, this packet could be a fragment. In this case, it will be fine if this packet doesn't need to protected; but if implementation can find a SA for this packet by matching selectors, the IPSec implementation can not send out this packet right away, it has to wait until it receives all the fragments of the datagram. Then (I)It has to reassemble them into a whole IP packet (II) IPSec processing (encryption and digestion) (III) then do fragmentation. The performance could be improved if the implementation doesn't reassemble the fragments, actually it can still fragment each piece separately if it can calculate the fragment offset by taking count in the security protocol header size and extra IP headers. But because the IPSec packet could be fragmented again and again during the route, receiver will have difficulties on figuring out the correct order between IPSec process and reassembly. Sorry for bothering you. However, Microsoft won't have these problems. :-) Appreciate your time!! Xuechen ~~~~~~~~~~~~~~~~~~~~ Xuechen Yang Vice President Engineering xuechen@osgroup.com (512)322-0676 ~~~~~~~~~~~~~~~~~~~~ Ashley Laurent, Inc. www.osgroup.com 707 West Avenue, #201 Austin TX, 78701 ~~~~~~~~~~~~~~~~~~~~ From owner-ipsec Tue Jan 13 02:02:56 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id CAA09544 for ipsec-outgoing; Tue, 13 Jan 1998 02:00:01 -0500 (EST) Message-Id: <3.0.1.32.19980113102324.00690c84@192.9.200.10> X-Sender: srinu@192.9.200.10 X-Mailer: Windows Eudora Light Version 3.0.1 (32) Date: Tue, 13 Jan 1998 10:23:24 +0500 To: ipsec@tis.com From: "srinivasrao.kulkarni" Subject: Some Questions Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi All I have a question regarding "draft-ietf-ipsec-esp-v2-02.txt November 1997" can any one answer me. Do we need host-to-network convertion for ESP header ? If YES whether it should be done before ICV calculation or after ICV calculation ? your sincerely K. SrinivasRao From owner-ipsec Wed Jan 14 07:18:18 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA20782 for ipsec-outgoing; Wed, 14 Jan 1998 07:12:37 -0500 (EST) X-Sender: cynthia@mail.surfnetusa.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: cynthia@usenix.org From: cynthia@usenix.org (Cynthia Deno) Subject: USENIX SECURITY SYMPOSIUM Date: Tue, 13 Jan 1998 14:07:50 -0800 Sender: owner-ipsec@ex.tis.com Precedence: bulk Time is running out. Register now. USENIX SECURITY SYMPOSIUM January 26-29 San Antonio, Texas Review the program. See the quality. Register on-line. Last day for on-line registration: January 20 http://www.usenix.org/events/sec98/ Last day for faxed/postal registrations: January 21 Fax: 714.588.9706 Call 714.588.8649 if you'd like to speak to someone about the conference. ================================================================ USENIX is the Advanced Computing Systems Association. Its members are the computer technologists responsible for many of the innovations in computing we enjoy today. To find out more about USENIX, visit our web site: http://www.usenix.org. From owner-ipsec Wed Jan 14 14:53:52 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA25935 for ipsec-outgoing; Wed, 14 Jan 1998 14:50:44 -0500 (EST) Message-ID: <34BD258E.58A29E3C@mercury-3.hkr.se> Date: Wed, 14 Jan 1998 20:52:31 +0000 From: Andreas Olsson X-Mailer: Mozilla 4.03 [sv] (WinNT; I) MIME-Version: 1.0 To: ipsec@tis.com Subject: packet security Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi, My name is Andreas Olsson and im studying to soon become a computer-enginer I have started with my thesis which is about how secure packets can be transfered on the media. The OS is winNT and 95 and the protocols that im gonna check is: TCP/IP DDE DCOM PPTP I have read your RFC's about IP-security: http://www.globecom.net/(eng)/ietf/draft/draft-ietf-ipsec-arch-sec-01.shtml http://ds.internic.net/rfc/rfc1826.txt http://ds.internic.net/rfc/rfc1827.txt and find em good. The IP we run today, is it IPv4? I want to ask you if you know which algorithms encrypts the packets? In your RFC's you just say that the security lies in the keys. Later I want to do a practical research on this topic. I want to connect three computers, two of them are communicating and the third tries to snap up the information which is transfered. Do you know any downloadable programs or other help which I can use for this?? Do you have any material or know any links that I can check about my topic I would be glad if you could send them to me. Personally I find it quite difficult to find information about my topic, both the protocols and then how the packets are transfered. Hope from help from you thanks........... regards, andreas ____________________________ Andreas Olsson de9557@mercury-3.hkr.se Kristianstad University Sweden ____________________________ From owner-ipsec Thu Jan 15 05:56:52 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id FAA02173 for ipsec-outgoing; Thu, 15 Jan 1998 05:53:46 -0500 (EST) Date: Thu, 15 Jan 1998 10:59:16 +0000 (GMT) From: George Tsirtsis To: IPSEC Subject: NAT bypass for e2e 'sensitive' applications (e.g: IPSEC) Message-Id: Mime-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-1804928587-884861956=:1464" Sender: owner-ipsec@ex.tis.com Precedence: bulk ---559023410-1804928587-884861956=:1464 Content-type: text/plain; charset="us-ascii" Hi all and happy new year, The I-D attached to this e-mail is going to come out very soon and proposes a way to run IPSEC (and any other end2end 'sensitive' application) through a Network Address Translation (NAT) box. I hope you will find it interesting; your comments will be most appreciated. Here is the abstract This document attempts to generate discussion on methods to run end 2 end 'sensitive' protocols and capabilities, like IPSEC, on networks that use Network Address Translators (NAT). The proposal does so by outlining one method to bypass NAT, when the required capabilities cannot be supported by NAT. The method uses a tunnel between a local host and the NAT box in order to dynamically allocate addresses to those hosts that need to communicate with external networks. With an allocated external address, the local hosts are able to communicate with external hosts without breaking the end 2 end principle. This proposal does not introduce any new protocols, it simply reuses existing protocols to provide an example solution. Best Regards George Tsirtsis ----------------------------- Internet Transport Research | BTLABS | -------------------------------------------------------------------------- Notice: This contribution is the personal view of the author and does not necessarily reflect the technical nor commercial direction of British Telecommunications plc. -------------------------------------------------------------------------- ---559023410-1804928587-884861956=:1464 Content-type: text/plain; charset="us-ascii" INTERNET-DRAFT George Tsirtsis, BTLABS Alan O'Neill, BTLABS January 1998 NAT Bypass for End 2 End 'sensitive' applications Status of this Memo This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts). Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress." Please check the I-D abstract listing contained in each Internet Draft directory to learn the current status of this or any other Internet Draft. Abstract This document attempts to generate discussion on methods to run end 2 end 'sensitive' protocols and capabilities, like IPSEC, on networks that use Network Address Translators (NAT). The proposal does so by outlining one method to bypass NAT, when the required capabilities cannot be supported by NAT. The method uses a tunnel between a local host and the NAT box in order to dynamically allocate addresses to those hosts that need to communicate with external networks. With an allocated external address, the local hosts are able to communicate with external hosts without breaking the end 2 end principle. This proposal does not introduce any new protocols, it simply reuses existing protocols to provide an example solution. Terminology Application In this document the term application refers to anything that uses the IP network protocol (IPSEC, FTP etc). L2TP In this document only the end 2 end flavour of L2TP is considered (otherwise known as PPTP) were the Host and the L2TP Access Concentrator (LAC) are both in the Host and only the connection between LAC and L2TP Network Server (LNS) goes across the network. Bypass the NAT This means that the Address Translation function is bypassed, NOT the NAT box, since the tunnel that bypasses the translation function, MAY terminate at a Router combined with a NAT box. 1. Introduction and Motivation Network Address Translation (NAT) is used today as an interim solution to the problem of limited address space in IPv4. One can design a network using private address space (not globally unique)and use NAT in order to allow communication with external networks. The NAT typically has only a small number of external addresses available, resulting in savings in the IPv4 address space. Unfortunately, address translation breaks one of the fundamental principles of Internet; the End 2 End Principle [ROUT]. This recommends that packets flow end to end, between hosts, without anyone changing its contents along the path. A number of applications have been designed with that principle in mind and any attempt to change the contents of their packets results in failure of the application. NAT does exactly that; for outgoing traffic it replaces the source private address of a hosts with an externally routable source address and replaces the corresponding private destination address for return traffic. This change of the address on transit works with a number of applications wile others can be fixed, e.g: FTP, by using Application Layer Gateways (ALG) to also translate appropriate fields in the higher layers (e.g: TCP checksum) in order to 'hide' from the other end the fact that something has changed in the packet. In other applications, however, the use of ALGs is either too inefficient, to be practicable (e.g: Mobile IP), or they bridge a very important part of the application in question (e.g: in IPSEC you have to trust the ALG/NAT - not always possible). Note that the complete list of applications that break with NAT is a current NAT WG item. This proposal provides a way to allow hosts, in networks that use NAT, to communicate with external hosts without breaking the end 2 end principle. In order to achieve the above functionality, a tunnel has to be built between the host in the private network and the NAT. The tunnel is then used to allocate an external address, out of the pool of addresses available to the NAT, as well as to route the packets outside the private network. 1.1. Assumptions The NAT box MUST be able to handle tunnels on the interface attached to the private network. This should not be very difficult since NAT boxes are usually integrated with routers. L2TP tunneling is assumed in this draft due to its extended functionality, but other types of tunneling MAY also be used. It would also be helpful if the host could establish the tunnel to the NAT without human intervention. Alternatively, the tunnel MAY be statically configured and ONLY used when an application is end 2 end sensitive. 1.2. Applicability and Limitations * This proposal does not solve problems that are inherent to NAT. In fact it does not change anything in the NAT or any other protocol. It merely bypasses NAT when the required functionality cannot be supported by NAT. * This proposal could be used by networks that use private address space, with a small number of users that need to run applications that break through NAT. Hosts that do not need, or are not allowed by local policy, to run this kind of applications, can still use NAT in the traditional way but SHOULD NOT be allowed to use the tunnel. * The network designer who is going to use the described mechanism needs to balance between the number of global addresses available, the total number of hosts in the private network and the number of users that are allowed to bypass the NAT at the same time. * It is clear that when an address is allocated to a tunnel it can not be overloaded by muxing the port numbers (NAPT function) * With this proposal NAT becomes an overloaded box. Apart from address translation, it is required to be able to handle tunnels, address allocation and potentially PPP, radius etc. * The use of L2TP, that carries PPP packets, allows for the use of access related protocols like RADIUS, providing policy and potentially an accounting mechanism. * NAT with the functionality described in this proposal is not transparent to the users that use the added functionality, since they need to know where to terminate the tunnel. * NAT becomes a single point of failure for users who access it through tunnels. As far as the author understands, hot standbys may be problematic since the tunnel configuration may be difficult to transfer. * The use of a tunnel creates an added overhead due to tunnel headers. Header compression mechanisms for L2TP are currently investigated in [L2TPHC] 2. Requirements The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in [KEYWORDS]. 3. Overview Consider the private network in Figure 1 connected through NAT to the global Internet. Hosts A and B can communicate with Host C using NAT in order to translate their private addresses to global addresses, which are valid in the Internet. +---------+ | Private | +------------+ +-------+ | Network | +-----+ | | +-------+ | HostA |=|=========|=| NAT |--| Internet |--| HostC | +-------+ | L2TP /| +-----+ | | +-------+ | / | +------------+ +------+--+ | +-----+ |HostB| +-----+ Figure 1: Tunneled connection through NAT. Lets assume that one of the hosts, say Host A, wants to set-up an IPSEC tunnel to Host C. In order to do that Host A needs a global address that is valid end to end and is not going to be changed by the NAT box. In order to do get a global address, Host A initiates an L2TP tunnel between itself and the NAT. With normal L2TP operation, virtual interfaces are set-up in both Host A and NAT, PPP parameters are negotiated and an address, from the pool of global addresses located in the NAT, is assigned to Host A. At the end of this procedure Host A has an IP connection running over the L2TP tunnel to the NAT, using an address valid to the global Internet. From then on, Host A can initiate a number of applications that normally would not run through the NAT, including IPSEC to Host C. All subsequent communication to Host C is transmitted through the L2TP tunnel in both directions and the NAT acts as a normal router without translation taking place. The tunnel SHOULD be disconnected or at least deactivated after the session is finished and the global address MUST be returned to the NAT's pool of addresses. 4. Why Tunneling The allocation of a globally unique address to a host in a private network is an obvious solution to networks that use NAT. This, however, creates an oxymoron in the sense that NAT is used in order avoid providing global addresses to all hosts in a network. One could argue that if a hosts has to run applications like IPSEC frequently it might make sense to have a global address permanently allocated to it. The problem is that this is a static solution which means that even when this host does not uses its global address, the address can not be used by others. Additionally, most applications are associated with a user not a host, e.g: IPSEC is a user's decision. It can also be argued that DHCP could be used to temporary allocate a global address. This is also problematic since the allocated address is not routable in the private domain leading to scaling problems. With Tunneling the routing problem is resolved, because the tunnel is routed on the private address. L2TP also has the added advantage that it is configured relatively automatically and may carry PPP. The latter allows the NAT to authenticate users that want to use the added functionality applying local policy, since this is clearly an expensive function. 5. SECURITY CONSIDERATIONS There are no security problems created by this proposal further to these described in the protocols used. 6. OPEN ISSUES The authors do not claim to be experts on either IPSEC nor L2TP and as such, help is required to investigate and clarify the details of this proposal. A host that wants to use the functionality described needs to know the address of the NAT. Can this be automated? Is it possible for the tunnel to be initiated automatically when IPSEC is to be used without human intervention? Remember that the tunnel has to be set-up and an address to be allocated before the host can initiate IPSEC. REFERENCES [KEYWORDS] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [NAT] P. Srisuresh, et.al., The IP Network Address Translator (NAT), ftp://ietf.org/internet-drafts/draft-rfced-info-srisuresh-03.txt, September 1997 [L2TP] K. Hamzeh et.al., Layer Two Tunneling Protocol "L2TP", ftp://ietf.org/internet-drafts/draft-ietf-pppext-l2tp-08.txt, November 1997 [L2TPHC], A.J. Valencia, L2TP Header Compression (``L2TPHC''), ftp://ietf.org/internet-drafts/draft-ietf-pppext-l2tphc-01.txt, December 1997 [ROUT] C. Huitema, Routing In The Internet, 1995, Prentice Hall. AUTHORS George Tsirtsis Internet Transport Group B29 Room 129 BT Laboratoties Martlesham Heath IPSWICH Suffolk IP5 3RE England Phone: +44 1473 640756 Fax: +44 1473 640709 e-mail: george@gideon.bt.co.uk Alan O'Neill Internet Transport Group B29 Room 129 BT Laboratoties Martlesham Heath IPSWICH Suffolk IP5 3RE England Phone: +44 1473 646459 Fax: +44 1473 640709 e-mail: alan.oneill@bt-sys.bt.co.uk DISCLAIMER Notice: This contribution has been prepared to assist the IETF as a basis for discussion. It is not a binding proposal on British telecommunications plc; specifically, British Telecommunications plc reserves the right to modify, delete and amend any statements contain herein. ---559023410-1804928587-884861956=:1464-- From owner-ipsec Thu Jan 15 07:28:10 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA02725 for ipsec-outgoing; Thu, 15 Jan 1998 07:22:47 -0500 (EST) Date: Wed, 14 Jan 1998 17:57:02 -0600 (CST) From: Tylor Allison X-Sender: allison@jiffy.sctc.com To: ipsec@tis.com, anx-sec@netrex.net Subject: ISAKMP Certificate Request Syntax Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk I have a few questions regarding how ISAKMP certificate request payloads are generated that I'm hoping some of you folks can answer. o Distinguished Name Attribute Type. The ISAKMP draft (v8) states: "Certificate Authorities (variable length) - Contains a list of Data Attributes (see section 3.3) which indicate the Distinguished Names of acceptable certificate authorities. See [IPDOI] for the Distinguished Name Attribute Type value." However, there is no DN Attribute Type defined in the IPSEC DOI (v6). There is an ID type (used for ID payloads) which is defined for DN's (ID_DER_ASN1_DN)... Is this what people are using for the attribute type? o Encoding ASN.1 DN's as attributes. The ISAKMP draft (v8) states that variable length attributes (like the DN Attribute Type above) must be aligned in 4-byte blocks. "If the Attribute Value is not aligned at a 4-byte multiple, the field is right justified and the remaining bits MUST be prepending with 0 for 4-byte alignment." Once so aligned, how does one go about retrieving the original data? Due to the alignment and the right justification, the original beginning of the data is not known (nor is the original length). OK, for ASN.1 I know that the first byte of the data is not zero ... it's an ASN.1 tag. But doesn't this pose a problem when used for encoding arbitrary attribute values (where the original data may already be prepended with 0's)? Any help would be greatly appreciated... Thanks! --- Tylor Allison tylor_allison@securecomputing.com (612) 628-1554 Secure Computing Corporation From owner-ipsec Thu Jan 15 10:43:51 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA04601 for ipsec-outgoing; Thu, 15 Jan 1998 10:41:59 -0500 (EST) Date: Thu, 15 Jan 1998 09:36:46 -0600 (CST) From: Tylor Allison X-Sender: allison@jiffy.sctc.com To: anx-sec@netrex.net, ipsec@tis.com Subject: ISAKMP info-exchange/notify handling Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk I have a few more questions about ISAKMP, this time regarding the use of ISAKMP Info exchanges and/or Notify/Delete payloads in response to error handling: o Reading the ISAKMP draft (v8), I'm lead to believe that a new ISAKMP Information Exchange is generated when ISAKMP hits an error condition. For example, section 5.2 under verifying cookies: "An Informational Exchange with a Notification payload containing the INVALID-COOKIE message type MAY be sent to the initiating entity. This action is dictated by a system security policy." Similar wording is used for other erroneous conditions. I then find the following text in the IPSEC DOI (v6), Section 4.6.3 "IPSEC DOI Notify Message Types: Notification Status Messages MUST be sent under the protection of an ISAKMP SA: either as a payload in the last Main Mode exchange; in a separate Informational Exchange after Main Mode or Aggressive Mode processing is complete; or as a payload in Quick Mode Exchange." I'm assuming that this last paragraph was meant to be applied to the IPSEC DOI Notify message types... but I have a question about whether or not any ISAKMP Notify or Delete Payload may be placed in the payload of a Main Mode, Aggressive, or Quick Mode exchange? So instead of generating a new ISAKMP Info exchange when responding to an error condition, I would just fill out the next payload of the exchange with the corresponding Notify or Delete Payload??? If this type of processing is allowed, does it contradict with the text in the ISAKMP draft mentioned above? I've been assuming that an Informational Exchange should always be generating in response to an error... even tho' I'll still handle notify or delete payloads in any exchange. o My next question concerns Informational Exchanges in response to Quick Mode negotiations. The I/O resolution draft states, Section 5.7: "As noted the message ID [of the ISAKMP info exchange] in the ISAKMP header-- and used in the prf computation-- is unique to this exchange and MUST NOT be the same as the message ID of another phase 2 exchange which generated this information exchange." In an environment where PFS is not performed, ISAKMP SA's may be used to protect more than one Quick Mode negotiation. How does one then know what Quick Mode negotiation an informational exchange is for? The ISAKMP draft says: "Notification which occurs during, or is concerned with, a Phase 2 negotiation is identified by the Initiator and Responder cookie pair in the ISAKMP Header and the Message ID and SPI associated with the current negotiation." This confuses me... the Message ID is lost (since we generate a new message ID for the Info exchange), we may not have the SPI value (e.g. Invalid IPSEC SA offered), or we may have multiple SPI's (e.g. QM negotiations with more than one IPSEC SA). Am I missing something? Are people using something other than the SPI's negotiated with the IPSEC SA's for their SPI's in notify/delete payloads? If not, how does one tie a specific Info exchange with the Phase 2 negotiation it is in response to? Sorry so long-winded, any help would be appreciated... Thanks! --- Tylor Allison tylor_allison@securecomputing.com (612) 628-1554 Secure Computing Corporation From owner-ipsec Thu Jan 15 14:08:16 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA06115 for ipsec-outgoing; Thu, 15 Jan 1998 14:05:04 -0500 (EST) Message-Id: <3.0.5.32.19980115141624.009ceb10@homebase.htt-consult.com> X-Sender: rgm-sec@homebase.htt-consult.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 15 Jan 1998 14:16:24 -0500 To: ipsec@tis.com From: Robert Moskowitz Subject: Job Change Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Effective January 16, 1998 I am resigning from my position at Chrysler Corporation. I am taking a position as a Senior Technical Director in the Research, Outreach, and Strategy Group at International Computer Security Association (ICSA, formerly known as NCSA). I am looking forward to leading the world-wide effort to develop certification standards for Virtual Private Networking (VPN) starting with IPsec and Certificate Authority (CA) technologies, and to assist the ICSA lab in certifying vendor products to these standards. Thus I will be working even closer to the vendors on this list than I have in the past. ICSA will announce this move monday at the RSA conference, and then I expect to spend much of my time there setting up vendor relationships (beyond those I already have). ICSA wants me to continue in my roles at the IETF. They see the value to the knowledge I gain and the contributions I make. This address is my 'security' address until I get Email set up at ICSA. My personal address is rgm@htt-consult.com My new work address is rgm@icsa.net From owner-ipsec Fri Jan 16 16:26:20 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA15869 for ipsec-outgoing; Fri, 16 Jan 1998 16:14:38 -0500 (EST) Date: Fri, 16 Jan 1998 16:27:07 -0500 Message-Id: <199801162127.QAA00888@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: "C. Harald Koch" Cc: rgm3@chrysler.com, ipsec@tis.com In-Reply-To: C. Harald Koch's message of Thu, 15 Jan 1998 14:28:01 -0500, <98Jan15.142815est.11649@janus.tor.securecomputing.com> Subject: Re: IPSEC Standard Status? Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-ipsec@ex.tis.com Precedence: bulk From: "C. Harald Koch" Date: Thu, 15 Jan 1998 14:28:01 -0500 Have the IPsec documents been submitted to the IESG yet? No; a number of document editors need to submit revisions based on the discussions we had in Washington. I've cc'ed this message to the IPSEC mailing list. If you are a document editor who needs to get a new version of your document to Internet Drafts, please considered yourself ping'ed, and I'd appreciate it if you could get the final changes done as soon as you can. Thanks! - Ted From owner-ipsec Fri Jan 16 16:35:38 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA16003 for ipsec-outgoing; Fri, 16 Jan 1998 16:32:30 -0500 (EST) From: "Alexei V. Vopilov" To: "IPsec MailList" Subject: need some food? Date: Sat, 17 Jan 1998 00:45:19 +0300 Message-ID: <01bd22c8$0a4f1380$e3253ac3@ppalx> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.71.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3 Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi, all. Being as many of others who has this list as the only 'newspaper' about what is going on with the network layer security I feel that there are no much news here (should I consider that as the good news? ;-). >From the very beginning I'm waiting for the round where IPsec WG will define the abstractions on how to manage all these secured bits on the desktop, on Enterprise, on Internet? For me, it sounds that to deliver such words as transparence, interoperability, flexibility, etc. the IPsec has to have very improved yet secured management model. I did some paper, which is too common and somewhere ambiguous, so I won't put these 9 pages directly on your screen. If you feel frozen with current state of network security development and want spend time to read, then look at: http://www.telekom.ru/users/alx/IPsecTopView.htm Anyway, I will be happy if some paragraphs from there will bring a food to discuss the new things here. I will not resist to just throw the rest of my paper then ;-) regards, --- Alexei From owner-ipsec Sun Jan 18 09:34:14 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA27730 for ipsec-outgoing; Sun, 18 Jan 1998 09:27:30 -0500 (EST) Date: Sun, 18 Jan 1998 09:38:58 -0500 Message-Id: <199801181438.JAA03444@rsts-11.mit.edu> To: ipsec@tis.com Subject: Minutes for the Washington IETF meeting From: tytso@MIT.EDU Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi all, My apologies for the lateness of these minutes. As I mentioned before, I had to reconstruct the minutes from notes that were taking, since we had neglected to appoint a scribe. My thanks to John Linn, Richard Graveman, and Tatu Ylonen for graciously sending me copies of their notes; this was a great help in creating these minutes. If you could look over these minutes and offer any corrections quickly, I would appreciate it. The deadline for the submission of minutes is fast approaching. Thanks! - Ted IETF Munich IPsec Working Group Meeting Minutes The IPSEC working group met on Tuesday, December 9th, 1997, at the IETF meeting in Washington, D.C. The Agenda was as follows: Agenda Review 1545-1550 Results of the Document Reading Party 1550-1620 Next Steps on Documents 1620-1630 IPSECOND issues Multicast key management 1630-1645 Policy management 1645-1705 Tunnel Management 1705-1710 MIB 1710-1715 IANA Registration 1715-1720 IPSECOND Scoping 1720-1735 The following items were added to the agenda: SSH ISAKMP test web page Next workshop SecureID Draft Convergence Results of the Document Reading Party ===================================== Bob Moscowitz reviewed the procedure which we followed the previous night to review the documents. In total, approximately 25-30 people attended, and split up into teams to review sets of two or three documents, checking for consistency amongst the set of the documents, as well as problems internal to the documents. Notes from the various teams were collected, to be published to the IPsec mailing list. A large number of issues that were identified were related to the Architecture document, and Stephen Kent presented those issues in his presentation. (Slides to be included in the minutes.) Next step on documents ====================== There are currently a set of 12 documents. Document editors will make another last set of changes, ask for comments to the list, and we will be entering last call on the documents very shortly. Multicast key management ======================== Dan Harkins from Cisco and Naganand Doraswamy from Bay Networks presented a proposal for a multicast key management, MKMP. MKMP is intended to provide scalable and secure distribution of multicast keys. It assures liveness, key doesn't cross wire (even encrypted), except on rekey operation. Routers do not need join secure multicast group, and it is independent of underlying m-cast routing. MKMP uses IPsec to secure multicast traffic and ISAKMP/Oakley-type messages for KM. MKMP-aware routers can become Group Key Distributors; the Group Information Tuple enforces access and delegates key distribution authority. Uses an ALL-MKMP-BOXES group. Key acquisition is separate from group join. To create a secure group, group key manager creates key, list of candidate key distributors, and access control info. Periodic key distributor solicitations sent to multicast group address; if message reaches candidate group key distributor, it obtains key from group key manager using key distribution protocol. Only routers already on the distribution tree become GKDs. Next steps are to clean up and issue draft MKMP specification. MKMP may require a separately chartered WG, but won't be considered by IESG until current IPsec docs passed. Policy management ================= Policy means different things to different people. It was referenced in the original documents, but there was only modest support in the protocols. Does there need to be a protocol to support policy management? Straw poll indicates a modest number of people agrees. Someone pointed out that there is ongoing work in this area within the Radius group. Others are concerned that this is not purely a protocol issue, and that policy management may not be well understood enough for us to design a protocol, let alone standardize it. BBN has some on-going work in this area. IBM also is doing some work in describing policies within LDAP. Note: this area can be an unbounded research topic unless strict requirements are used to bound the problem. Tunnel Management ================= There have been several drafts that have been submitted on this topic. There is some overlap between tunnel management and the work in the VPN BOF. Someone from Timestep commented that we must understand what we want to accomplish, we must do this in a standard way so that we don't have all these proprietary methods to configure. MIB === There's not much to say about MIB's, except that one is required for elevation to Draft Standard. (Since we will be elevating the current drafts to Proposed Standard, this is not an immediate issue.) Rodney Thayer and Uri Blumenthal are interested in working on this. IANA Registration ================= Rodney is looking into the requirements for IANA registrations; we need to specify procedures for allocating algorithm identifiers for the future. [Note: after the meeting, I have learned that we need to this before we the drafts go to the IESG. This is an issue which can't wait for IPSECOND. --- Ted] IPSECOND Scoping ================ Ted then led a brain-storming session about future work items which should be included in the IPSECOND work. The following items were identified by the working group as being additional items follow-on work should consider. - agenda discussion moved to mailing list - question about SNMP - "i have a solution" guy, draft: draft-ietf-firewallmib-19.txt? - JI: IPsec currently good for vpns and remote access; several efforts in other groups to secure individual protocols. How can we take out the security done in other protocols, and make them use IPsec? - Dan McDonald (Sun's IPsec guy): being good for vpn's isn't the way it was designed, this is how it was implemented - Eric Rescorla: using IPsec may not be feasible for application protocols, even though you may be able to use IPsec key management for them - disa guy: suggests focusing exclusively on IPv6 ISAKMP test web page ==================== Tero Kivinen gave a presentation of an ISAKMP test web page which has been made available by SSH Communications Security in Finland. The URL for the web page is: "http://isakmp-test.ssh.fi/". All of the popular algorithms are available. For demonstration purposes can be used to test against itself. In answer to questions about future interoperability sessions, Bob Moscowitz indicated that while the ANX (as a customer) was not intending to sponsor any further interopability sessions, other vendors are stepping up to sponsor these activities. Other interoperability session is being planned for mid-Febuary; Cisco as offered facilities for this session. SecureID and ISAKMP =================== Roy Pereira from TimeStep had published an ISAKMP/SecurID integration I-D shortly before the meeting. There is another I-D written by New Oak as well. The authors are planning to align the drafts. From owner-ipsec Sun Jan 18 12:09:48 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA28681 for ipsec-outgoing; Sun, 18 Jan 1998 12:08:35 -0500 (EST) Date: Sun, 18 Jan 1998 12:18:45 -0500 (EST) X-Sender: kent@po1.bbn.com (Unverified) Message-Id: In-Reply-To: <98Jan10.000206est.11657@janus.tor.securecomputing.com> References: Your message of "Fri, 09 Jan 1998 16:54:33 -0500". Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: "C. Harald Koch" From: Stephen Kent Subject: Re: implicit padding for authentication Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Harold, Yes, we could do that, as another way of saying that we don't do padding if the integrity algorithm has its own padding scheme. However, I'd rather not use that semantic trick, as it may confuse folks who know that these hash algorithm do have a block size requirement. I'd rather be more strainghforward about this and just reword the text, either to say that the algorithm must specify the padding sceheme, or that we have a default that can be overidden by the algorithm. Steve From owner-ipsec Mon Jan 19 11:30:13 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA06592 for ipsec-outgoing; Mon, 19 Jan 1998 11:21:52 -0500 (EST) Message-Id: <3.0.1.32.19980119190024.006946a0@192.9.200.10> X-Sender: srinu@192.9.200.10 X-Mailer: Windows Eudora Light Version 3.0.1 (32) Date: Mon, 19 Jan 1998 19:00:24 +0500 To: ipsec@tis.com From: "srinivasrao.kulkarni" Subject: Your questions Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi All, I have some questions regarding "draft-ietf-ipsec-esp-v2-02.txt November 1997". As far as I know, if any header contains a variable length of data then it will have a field for the length of that variable field. But, I found that in case of ESP header there is no field that gives the payload length and authdata length whereas in AH header it has payload len. From the payload length, the authdata length can be determined easily. Is it that the length field is missing in ESP header format or is it not part of the header? And one more thing is that pad length is given for the padding field which is also of variable length. Assuming that the datagram has been read into a buffer, how can we access the ESP trailer in it since the authentication data which succeeds the ESP trailer and the payload data and padding which precede the trailer are both variable length fields? It was said w.r.t draft-ietf-ipsec-auth-hmac-sha196-01.txt Nov 1997 HMAC-SHA-1-96 produces a 160-bit authenticator value. This 160-bit value can be truncated as described in RFC2104. For use with either ESP or AH, a truncated value using the first 96 bits MUST be supported. Upon sending, the truncated value is stored within the authenticator field. Upon receipt, the entire 160-bit value is computed and the first 96 bits are compared to the value stored in the authenticator field. No other authenticator value lengths are supported by HMAC-SHA-1-96. My question is how does the receiver know whether the authdata is truncated or not i.e is it 96-bit or 160-bit without specifying the length in the ESP header ? Than 'Q' Your Sincerely SrinivasRao. B. Kulkarni Rendezvous On Chip Pvt Ltd. First Floor, Plot No. 14, NewVasaviNagar, Kharkhana, SECUNDERABAD - 500019. Ph : (040)7742606 email address : srinu@trinc.com From owner-ipsec Mon Jan 19 23:20:31 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id XAA10480 for ipsec-outgoing; Mon, 19 Jan 1998 23:18:03 -0500 (EST) Message-Id: <3.0.1.32.19980120093340.006a99a4@192.9.200.10> X-Sender: rohit@192.9.200.10 X-Mailer: Windows Eudora Light Version 3.0.1 (32) Date: Tue, 20 Jan 1998 09:33:40 +0500 To: ipsec@tis.com From: rohit Subject: Question Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk HI All I have a question regarding selecting and using an SA or SA Bundle during the processing of Inbound IPSEC traffic. In draft-ietf-ipsec-arch-sec-02.txt by Randall Atkinson, November 1997 on page 30, it says that " 2. Use the SA found to do the IPsec processing, e.g., authenticate and decrypt. This step includes matching the packet's ( Inner Header if tunneled ) selectors to the selectors in the SA. " My Question is If the received packet has been encrypted with AH as well as ESP protocols, then the data following the ESP header will be encrypted, so how can we able to get the Inner IP header's selectors for comparing them with the SA's selectors ? Thanks in Advance Rohit Rohit Aradhya Rendzevous Onchip Pvt Ltd. First Floor, Plot No 14 New Vasavi Nagar, Karkhana Secunderbad -500019. Phone No : (040)7742606 email address : rohit@trinc.com From owner-ipsec Mon Jan 19 23:54:29 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id XAA10723 for ipsec-outgoing; Mon, 19 Jan 1998 23:54:02 -0500 (EST) Message-Id: <199801200505.VAA27198@greatdane.cisco.com> To: rohit cc: ipsec@tis.com Subject: Re: Question In-reply-to: Your message of "Tue, 20 Jan 1998 09:33:40 +0500." <3.0.1.32.19980120093340.006a99a4@192.9.200.10> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 19 Jan 1998 21:05:16 -0800 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk AH doesn't encrypt so you don't have to worry about that. But more to your question.... If you've found the SA and finished IPSec processing on the packet (e.g. authenticate and decrypt) then the packet is authenticated and decrypted. You're free to inspect inner headers since they're now in the clear. If the inner packet itself is encrypted with ESP then check whether the SA under which you processed the packet was created with the protocol selector = ESP, or whether it was wildcarded. If either then pass; if not, drop. ISAKMP allows for protocol and port as well as address (and wildcards on any or all) to constrain IPSec SAs upon creation. It is incumbent upon implementations to check that the processed packet matches the characteristics of the SA with which it was processed. If someone sends you a ftp packet to host X protected by an SA that was created for telnet to host Y then drop the packet. Dan. > I have a question regarding selecting and using an SA or SA Bundle > during the processing of Inbound IPSEC traffic. > > In draft-ietf-ipsec-arch-sec-02.txt by Randall Atkinson, November 1997 > on page 30, it says that > > " 2. Use the SA found to do the IPsec processing, e.g., authenticate and > decrypt. This step includes matching the packet's ( Inner Header if > tunneled ) selectors to the selectors in the SA. " > > My Question is > > If the received packet has been encrypted with AH as well as ESP > protocols, then the data following the ESP header will be encrypted, so how > can we able to get the Inner IP header's selectors for comparing them with > the SA's selectors ? > > > Thanks in Advance > Rohit From owner-ipsec Tue Jan 20 10:53:58 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA14902 for ipsec-outgoing; Tue, 20 Jan 1998 10:48:06 -0500 (EST) Message-Id: <3.0.5.32.19980120105915.0099f720@homebase.htt-consult.com> X-Sender: rgm-sec@homebase.htt-consult.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Tue, 20 Jan 1998 10:59:15 -0500 To: ipsec@tis.com From: Robert Moskowitz Subject: March IPsec workshop! Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk This is the announcement of the next IPsec workshop, the week of March 2, 1998. It is hosted by CISCO at their Raleigh, NC facility. ICSA (previously NCSA, my new employer) and the AIAG will be participating, assisting in developing the testing criteria. Details for the workshop will be forthcoming as soon as Cisco and I can work them out. Last week a group of IPsec-ers had a meeting at the RSA conference which will be the framework for the testing. All interested vendors, have your representative contact me at this address. I will put together a distribution list for participating vendors. All interested consumers, also contact me, indicating that you are a consumer. I will work with Cisco to see what room we might have for consumers that wish to roll up their sleeves and work closely with the vendors. I am also inviting CA vendors/service houses to provide multiple CA products for Oakley testing. There will be followup on this item on the PKIX list (permission granted by the co-chairs). Robert Moskowitz ICSA Security Interest EMail: rgm-sec@htt-consult.com From owner-ipsec Tue Jan 20 15:51:14 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA17322 for ipsec-outgoing; Tue, 20 Jan 1998 15:46:17 -0500 (EST) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <3.0.1.32.19980120093340.006a99a4@192.9.200.10> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 20 Jan 1998 15:55:49 -0500 To: rohit From: Stephen Kent Subject: Re: Question Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Rohit, I saw Dan's Response to you message and just wanted to add to his comment. Specifically, on receipt, the lookup is performed based on dest IP addr, security protocol, and SPI. Thus lack of access to the port fields is not an issue for SA lookup. Consistent with what Dan noted, the arch doc calls for complete processing of all security protocols prior to checking against the SA parameters, so the port fields are available at that time. Steve From owner-ipsec Wed Jan 21 11:01:20 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA24063 for ipsec-outgoing; Wed, 21 Jan 1998 10:54:19 -0500 (EST) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <3.0.1.32.19980119190024.006946a0@192.9.200.10> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 21 Jan 1998 11:06:10 -0500 To: "srinivasrao.kulkarni" From: Stephen Kent Subject: Re: Your questions Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk >As far as I know, if any header contains a variable length of data then it >will have a field for the length of that variable field. But, I found that >in case of ESP header there is no field that gives the payload length and >authdata length whereas in AH header it has payload len. From the payload >length, the authdata length can be determined easily. Is it that the length >field is missing in ESP header format or is it not part of the header? > >And one more thing is that pad length is given for the padding field which >is also of variable length. Assuming that the datagram has been read into a >buffer, how can we access the ESP trailer in it since the authentication >data which succeeds the ESP trailer and the payload data and padding which >precede the trailer are both variable length fields? There is no need for an ESP header length field. ESP encapsulates its payload, so the length of the encapsulated payload, including the ESP header and trailer, can be determined from the IP total packet length field, minus the IP header length, the same way one would determine the size of a TCP or UDP payload. The ESP header is fixed length, 8 bytes. If auth data is present, it is fixed length for a specific SA, because the auth data length is determined by the algorithm that is negotiated for the SA, e.g., 12 bytes for the default algorithm. After removing the auth data (if present), one decrypts the ESP payload and removes the Next header field. Then one can work backwards from the pad length field to get to the real end of the ULP or tunneled IP packet. >It was said w.r.t draft-ietf-ipsec-auth-hmac-sha196-01.txt Nov 1997 > >HMAC-SHA-1-96 produces a 160-bit authenticator value. This 160-bit >value can be truncated as described in RFC2104. For use with either >ESP or AH, a truncated value using the first 96 bits MUST be >supported. Upon sending, the truncated value is stored within the >authenticator field. Upon receipt, the entire 160-bit value is >computed and the first 96 bits are compared to the value stored in >the authenticator field. No other authenticator value lengths are >supported by HMAC-SHA-1-96. > >My question is how does the receiver know whether the authdata is truncated >or not i.e is it 96-bit or 160-bit without specifying the length in the ESP >header ? Again, the length of the auth data is specified during SA establishment and then is constant for all traffic on the SA. Truncated and non-truncated versions of the same (keyed) hash are assigned different algorithm IDs and thus are distinguishable at the time of SA establishment. Steve From owner-ipsec Wed Jan 21 20:08:53 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA28192 for ipsec-outgoing; Wed, 21 Jan 1998 20:02:35 -0500 (EST) Date: Wed, 21 Jan 1998 20:12:34 -0500 (EST) X-Sender: kent@po1.bbn.com (Unverified) Message-Id: In-Reply-To: <199801111935.NAA06175@osgroup.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: "Xuechen Yang" From: Stephen Kent Subject: Re: some issues about IPSec Cc: Sender: owner-ipsec@ex.tis.com Precedence: bulk Xuechen, >I like to have your opinions on some issues. Basically we already got a >bump-in-the-stack implementation for Windows 95 and Windows NT working. >This implementation supports multiple security channels between two hosts >or host and security gateway or two security gateways. User can configure >which application protocol to protect (FTP, TELNET, HTTP...) and what kind >of algorithm to use. Now it only works with manual key management and only >in tunnel mode. Manual keying is not a problem, but the new I-Ds do require you to support both tunnel and transport modes, unless your BITS implementation is destined for use only on security gateways. At one time I proposed restricting BITS implementatiions to tunnel mode only, but at least one vendor was implementing transport mode and argued against that, so ... Also, there is a need to support administrative configuration that may be more sophisticated than the preceeding paragraph would suggest. >(1) Although we didn't intend to implement IPSec server (e.g. NT server >gateway) driver as well, we had to do internal test between two hosts and >they both had our IPSec drivers installed. We found out we have to let user >choose host type based on per protocol: CLIENT or SERVER. For instance: >assume we have two hosts A and B. We use A as a FTP server, and configure >both of them to enable IPSec protection and use same encryption algorithm >and authentication algorithm. If we try to FTP A from B, the IPSec >implementation on B has to check the destination port number combined with >destination IP address and transport type of every outgoing packet to >decide whether this packet should be applied with the SA which was assigned >to protect FTP channel between A and B. On the A (server) side, the IPSec >implementation has to check the source port number instead of destination >port number. Yes, this type of checking is consistent with the current specs, for a BITS implementation. >But of course, we can simply the approach: if either destination or source >port is equal to 20 or 21, driver applies the SA. But I don't think it's a >good way. That would not be consistent with the current specs, which require a check against source and destination IP addresses, next protocol, and, if applicable, port fields. >I thought another way and that is implied by your draft: In SPD, user has >to define both source port number and destination number for every >connection. Whenever user opens a socket, IPSec implementation will update >SPD and use the new source port number as a selector (on client side if the >destination number already existed as a selector). However, it's difficult >to implement for BITS. And I think it's more natural if we only let user >choose the well-known port number defined for server. On server side, >that's the source port; on the client side, that's destination port. There is no requirement that a user specify both source and destination port for every SA, i.e., ANY is an OK choice for either or both of these fields in the SPD. However, there is a requirement that your implementation allow a user to enumerate specific ports for both source and destination, if the user desires. Also note that an SPD entry might specify ANY for a source port and specify a given destinaion (well known) port, but call for a different SA each time a different source port is used. That behavior matches your characterization of updating the SPD whenever a new source port is selected by a user. Prior ot your message, I dont recall a suggestion that we define a different set of requirements for BITS implementations vs. native host implementations. Also, the roles of client and server may both apply to a given host, so a distinction made on this basis may not be a good idea. >(2) Fragmentation in transport mode for BITS >For the implementation of integrating IPSec into natural TCP/IP stack, >fragmentation won't be an issue. But for BITS implementation, fragmentation >is worth to mention in transport mode. The problem is when BITS-IPSec >implementation receives an outgoing packet from TCP/IP stack, this packet >could be a fragment. In this case, it will be fine if this packet doesn't >need to protected; but if implementation can find a SA for this packet by >matching selectors, the IPSec implementation can not send out this packet >right away, it has to wait until it receives all the fragments of the >datagram. Then (I)It has to reassemble them into a whole IP packet (II) >IPSec processing (encryption and digestion) (III) then do fragmentation. As you may recall, ESP and AH in transport mode are applied only to whole datagrams, not to fragments. This has been true for a long time, but you're right that it makes like more difficult for BITS and BITW implementations. This was part of my reason for suggesting tunnel-only mode for BITS, as noted above, but that's not what the WG decided to pursue. So, for now, you are required to assemble the fragments and apply ESP prior to transmission, in transport mode. To do otherwise would introduce a requirement to process ESP fragments for other host iplementations. So, the processing you describe above is precisely what must be supported in a BITS implementation. >The performance could be improved if the implementation doesn't reassemble >the fragments, actually it can still fragment each piece separately if it >can calculate the fragment offset by taking count in the security protocol >header size and extra IP headers. But because the IPSec packet could be >fragmented again and again during the route, receiver will have >difficulties on figuring out the correct order between IPSec process and >reassembly. I'm not sure what point you're trying to make here. The bottom line is that ESP is applied only to whole datagrams in transport mode. To do otherwise may pose problems for receiving hosts, e.g., in the face of missing port fields in later fragments. Steve From owner-ipsec Thu Jan 22 00:30:35 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id AAA29705 for ipsec-outgoing; Thu, 22 Jan 1998 00:27:38 -0500 (EST) X-Sender: dnessett@tdc.3com.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 21 Jan 1998 21:41:04 -0700 To: Stephen Kent From: Dan Nessett Subject: Padding complexities Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Steve, I think the padding issue may be a bit more complicated than might be first thought. The implicit padding rules of AH and ESP (for ICV computation) specify padding the message to equal the blocksize of the message digest algorithm. However, at least MD5 (I don't have FIPS 180-1 in front of me at the moment) will add an additional 448 bits (the first being a 1 and the remainder a 0) onto the end of a presented message with a length that is a multiple of 64 bytes, then add 64-bits that encode the length of the message to the end of that. Consequently, if an implementation strictly follows the existing internet drafts, it zero pads for AH/ESP then pads another 64 bytes according to the MD5 algorithm specification. Both the AH/ESP zero padding and the MD5 padding are not transmitted. While I agree that both AH and ESP should be changed so that the padding rules specified in the authentication algorithms are followed, a big question is what do existing implementations do? If they follow the existing AH and ESP specs and use a standard implementation of either MD5 or SHA-1, they would add an additional 64 bytes onto the end of a padded message. I am surprised that no implementors have addressed this issue on the list, since changing the AH and ESP specs could mean deployed implementations would fail to interoperate with those following the eventual standard. Dan From owner-ipsec Thu Jan 22 03:32:37 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id DAA00685 for ipsec-outgoing; Thu, 22 Jan 1998 03:26:36 -0500 (EST) Message-Id: <3.0.1.32.19980122122720.006b0964@192.9.200.10> X-Sender: rohit@192.9.200.10 X-Mailer: Windows Eudora Light Version 3.0.1 (32) Date: Thu, 22 Jan 1998 12:27:20 +0500 To: kent@bbn.com From: rohit Subject: Manual key management issues Cc: ipsec@tis.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi Steve, I have some questions regarding exchange of SPIs during Manual key management. 1. During Automatic key management, as we know, SPIs will be exchanged priorto any data transfer with the help of ISAKMP. But, how are the SPIs exchanged during Manual Key Management ? 2. Assuming that SPI is not exchanged prior to data transfer in manual key management, we thought of implementing the matching of incoming packet with the SAs by comparing the packet's Dest_address and Sec_protocol with the SA counterparts. If we found that more than one SAs are matched than we do an exhaustive processing and only process the packet with the totally matching SA. Is this strategy fine ? Or is it that for conformance to IPSEC, the SA has to be found by matching against the unique tuple (SPI, IPSEC proto,Dest Addr)? 3. Also, once again in manual key management, we are planning to create SAs for outgoing packets at run-time if a matching SA is not found in the SAD by generating a unique SPI value. When are the SAs for receiving packets created? Do we create SAs for the SPD entries in incoming direction at bootup time and they are static, i.e., remain until the system is rebooted? But, this might compromise the security if SAs remain for so long a period. Thanks in Advance Rohit Rohit Aradhya Rendzevous Onchip Pvt Ltd. First Floor, Plot No 14 New Vasavi Nagar, Karkhana Secunderbad -500019. India Phone No : (040)7742606 email address : rohit@trinc.com From owner-ipsec Thu Jan 22 03:49:06 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id DAA00808 for ipsec-outgoing; Thu, 22 Jan 1998 03:44:36 -0500 (EST) From: Dan McDonald Message-Id: <199801220856.AAA08261@kebe.eng.sun.com> Subject: Re: Padding complexities To: dan_nessett@3mail.3Com.COM (Dan Nessett) Date: Thu, 22 Jan 1998 00:56:11 -0800 (PST) Cc: ipsec@tis.com In-Reply-To: from "Dan Nessett" at Jan 21, 98 09:41:04 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk > While I agree that both AH and ESP should be changed so that the padding > rules specified in the authentication algorithms are followed, a big > question is what do existing implementations do? Existing implementations just feed in the message and let the algorithm's "Finish" routine close it out the way it sees fit. For example, consider a UDP/IPv4 datagram with one byte of data. IP (20 bytes) + UDP (8 bytes) + data (1 byte) Now AH is inserted, and let's use HMAC-MD5-96 for the algorithm... IP (20 bytes) + AH (24 bytes) + UDP (8 bytes) + data (1 byte) Now assuming an HMAC implementation has the same interface as the MD5 in RFC 1321, there are three functions: MD5init() MD5update() MD5final Now for HMAC, you have to feed in the key, fine. The _update_ is what's important, as that's what you feed bytes into. So I feed in 20+24+8+1 == 53 bytes (ugggh, pardon that number). I then call _final_, which pads implicitly and returns you a digest result. The receiving side does the same thing; it feeds in 53 bytes, and gets a digest after calling _final_. And you save valuable MTU cruft (the phrase "MTU plaque" seems fitting here) by not transmitting unnecessary padding on the wire. No real rocket science here; it's just left up to the algorithm. I can safely speak for SunOS 5.x, and Mentat, whom I've interoperated against. (BTW, I'm looking for more people to interoperate against, send mail to the address above, or see my .signature for a phone #.) I suspect others do the same, given what Marc told me about whom HE interoperated against. > If they follow the existing AH and ESP specs and use a standard > implementation of either MD5 or SHA-1, they would add an additional 64 > bytes onto the end of a padded message. No extra bytes are _added_ to messages with AH with the current set of algorithms. They are added to ESP ONLY so a block cipher doesn't choke on what it's fed. If it's DES or 3DES, you generate padding pre-encryption to round out the packet to the 8-byte block size of DES. My interoperability assertions apply here too. Hope this helps! -- Daniel L. McDonald - Solaris Internet Engineering || MY OPINIONS ARE NOT Mail: danmcd@eng.sun.com, danmcd@kebe.com <*> || NOT NECESSARILY SUN'S! Phone: (650) 786-6815 |"rising falling at force ten WWW: http://www.kebe.com/~danmcd | we twist the world and ride the wind" - Rush From owner-ipsec Thu Jan 22 04:07:16 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id EAA00932 for ipsec-outgoing; Thu, 22 Jan 1998 04:06:36 -0500 (EST) From: Dan McDonald Message-Id: <199801220919.BAA08327@kebe.eng.sun.com> Subject: Re: Manual key management issues To: rohit@trinc.com (rohit) Date: Thu, 22 Jan 1998 01:19:14 -0800 (PST) Cc: ipsec@tis.com In-Reply-To: <3.0.1.32.19980122122720.006b0964@192.9.200.10> from "rohit" at Jan 22, 98 12:27:20 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk > Hi Steve, Ummm, I'm not Steve, but since I just answered one IPsec question, I figure I'm almost on a roll... :) > 1. During Automatic key management, as we know, SPIs will be exchanged > priorto any data transfer with the help of ISAKMP. But, how are the SPIs > exchanged during Manual Key Management ? They are simply assigned with whatever value you want. You have to add a pair (inbound/outbound) to BOTH machines you wish to secure. > 2. Assuming that SPI is not exchanged prior to data transfer in manual key > management, Bad assumption... VERY bad assumption. > we thought of implementing the matching of incoming packet with the SAs by > comparing the packet's Dest_address and Sec_protocol with the SA > counterparts. If we found that more than one SAs are matched than we do an > exhaustive processing and only process the packet with the totally matching > SA. Is this strategy fine ? No... that strategy is dangerous. > Or is it that for conformance to IPSEC, the SA has to be found by matching > against the unique tuple (SPI, IPSEC proto,Dest Addr)? Yes, you MUST do this. If you receive a packet that does not have an SA matching , you MUST drop it, and you SHOULD/MUST issue a warning or log a failure or something. > 3. Also, once again in manual key management, we are planning to create SAs > for outgoing packets at run-time if a matching SA is not found in the SAD > by generating a unique SPI value. When are the SAs for receiving packets > created? They are created before packets are received. You have no other choice. This is why ISAKMP is important for a scalable IPsec solution. Manual keying, while necessary, is very annoying for frequent rekeying situations. > Do we create SAs for the SPD entries in incoming direction at bootup time > and they are static, i.e., remain until the system is rebooted? To answer your question, you have to create SAs before you can hope to receive IPsec-protected traffic. SA lifetimes are independent of how they were created. You can manually add an SA with a finite lifetime. You just better add another before that first one expires. > But, this might compromise the security if SAs remain for so long a period. Yes, long-lived SAs are a security risk. The IPsec architecture document makes (or if it doesn't, it should make) clear how inbound/outbound processing and SA creation interact. Basically: INBOUND PROCESSING: * Look up SA using * If SA lookup fails, drop the packet and log/notify/scream about the error. No ifs, ands, or buts. If an SA isn't there, you won't get the data protected by that SA. * If SA is present proceed to process the packet accordingly. OUTBOUND PROCESSING * Using SPD/selectors/whatever, find an appropriate SA. * If none exists, kick some keying entity in the pants to add an SA on your behalf that fits your policy. This entity is usually ISAKMP, but it doesn't have to be. * If no keying entity is found (or it returns an error, times out, etc.), drop the packet. * Otherwise, the keying entity will add the SA for you (and presumably your destination will now have one too) and then process the outgoing packet. Hope this helps! -- Daniel L. McDonald - Solaris Internet Engineering || MY OPINIONS ARE NOT Mail: danmcd@eng.sun.com, danmcd@kebe.com <*> || NOT NECESSARILY SUN'S! Phone: (650) 786-6815 |"rising falling at force ten WWW: http://www.kebe.com/~danmcd | we twist the world and ride the wind" - Rush From owner-ipsec Thu Jan 22 12:50:38 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA04816 for ipsec-outgoing; Thu, 22 Jan 1998 12:42:44 -0500 (EST) From: Jackie Wilson Message-Id: <199801221754.LAA22814@jhwilson.austin.ibm.com> Subject: Security Association Lifetimes in kbytes To: ipsec@tis.com Date: Thu, 22 Jan 1998 11:54:44 -0600 (CST) Cc: f13sipsec-l@austin.ibm.com X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk In order to get consistency in implementations of various IP Security products, I wanted to ask about implementing lifetimes in terms of kbytes. Is it assumed that we use the length field in the IP header? If so, won't the effect vary depending on IP V4/ IP V6 and various options that are selected that determine the number and size of headers and MTU sizes? How would an administrator know how much to increment the size to account for this type of overhead? How do we handle overlap to refresh the keys before the previous SA expires? Is this usually a user-configurable option of some percentage of the lifetime? Seems success at refreshing the keys would vary depending on whether the data is bursty or not. Can the tunnel expire in the middle of a packet, or do we implement it on packet boundaries? Do you toss the packet if the entire packet does not make it in the lifetime? Would appreciate your feedback. Jackie -- Jacqueline Wilson | Phn: (512) 838-2702 IBM, AIX/6000 | Fax: (512) 838-3509 11400 Burnet Road ZIP 9551 | Ext: 8-2702 Tie-Line: 678 Austin, TX 78758-3493 | inet: jhwilson@austin.ibm.com From owner-ipsec Thu Jan 22 13:05:50 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA04991 for ipsec-outgoing; Thu, 22 Jan 1998 13:02:39 -0500 (EST) Message-Id: <98Jan22.131405est.11652@janus.tor.securecomputing.com> To: Dan McDonald cc: dan_nessett@3mail.3Com.COM (Dan Nessett), ipsec@tis.com Subject: Re: Padding complexities References: <199801220856.AAA08261@kebe.eng.sun.com> In-reply-to: danmcd's message of "Thu, 22 Jan 1998 03:56:11 -0500". <199801220856.AAA08261@kebe.eng.sun.com> From: "C. Harald Koch" X-uri: X-Face: )@F:jK?*}hv!eJ}*r*0DD"k8x1.d#i>7`ETe2;hSD2T!:Fh#wu`0pW7lO|Dfe'AbyNy[\Pw z'.bAtgTM!+iq2$yXiv4gf<:D*rZ-|f$\YQi7"D"=CG!JB?[^_7v>8Mm;z:NJ7pss)l__Cw+.>xUJ) did@Pr9 Date: Thu, 22 Jan 1998 13:13:43 -0500 Sender: owner-ipsec@ex.tis.com Precedence: bulk In message <199801220856.AAA08261@kebe.eng.sun.com>, Dan McDonald writes: > > Existing implementations just feed in the message and let the algorithm's > "Finish" routine close it out the way it sees fit. Phrased another way, MD5 (and SHA1) are *designed* so that the internal blocksize of the algorithm is irrelevant. Unlike DES-CBC, you can feed any number of bytes into the algorithm, and get the correct result. MD5 and SHA1 have an effective (external?) blocksize of 1 byte, as I said previously. Meta comment: when was this issue of "authentication algorithm blocksize" introduced? As with many other changes in the last few months, it has added needless complexity and confusion to the standard. -- Harald Koch From owner-ipsec Thu Jan 22 13:18:25 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA05101 for ipsec-outgoing; Thu, 22 Jan 1998 13:13:40 -0500 (EST) Message-Id: <98Jan22.132603est.11651@janus.tor.securecomputing.com> To: ipsec@tis.com Subject: Authentication Padding From: "C. Harald Koch" X-uri: X-Face: )@F:jK?*}hv!eJ}*r*0DD"k8x1.d#i>7`ETe2;hSD2T!:Fh#wu`0pW7lO|Dfe'AbyNy[\Pw z'.bAtgTM!+iq2$yXiv4gf<:D*rZ-|f$\YQi7"D"=CG!JB?[^_7v>8Mm;z:NJ7pss)l__Cw+.>xUJ) did@Pr9 Date: Thu, 22 Jan 1998 13:25:45 -0500 Sender: owner-ipsec@ex.tis.com Precedence: bulk Never mind, I just went and re-read the AH draft: 3.3.3.2.2 Implicit Packet Padding For some authentication algorithms, the byte string over which the ICV computation is performed must be a multiple of a blocksize specified by the algorithm. If the IP packet length (including AH) does not match the blocksize requirements for the algorithm, implicit padding MUST be appended to the end of the packet, prior to ICV computation. The padding octets MUST have a value of zero. The blocksize (and hence the length of the padding) is specified by the algorithm specification. This padding is not transmitted with the packet. The key phrase is "FOR SOME AUTHENTICATION ALGORITHMS". Neither MD5 nor SHA-1 fall into this category. The DES MAC (defined in draft-bitan-auth-des-mac-00.txt) would fall into this category. Case closed, IMNSHO. I suppose, technically, the MD5 and SHA-1 drafts should be modified to explicitly declare the input blocksize requirements as "1-byte". -- C. Harald Koch "Madness takes its toll. Please have exact change." -Karen Murphy From owner-ipsec Thu Jan 22 14:49:45 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA05998 for ipsec-outgoing; Thu, 22 Jan 1998 14:46:55 -0500 (EST) Date: Thu, 22 Jan 1998 14:57:40 -0500 (EST) Message-Id: <199801221957.OAA14585@carp.morningstar.com> From: Ben Rogers To: Stephen Kent Cc: "Xuechen Yang" , Subject: Re: some issues about IPSec In-Reply-To: References: <199801111935.NAA06175@osgroup.com> Reply-To: ben@Ascend.COM (Ben Rogers) Sender: owner-ipsec@ex.tis.com Precedence: bulk Stephen Kent writes: > Xuechen, > > >I like to have your opinions on some issues. Basically we already got a > >bump-in-the-stack implementation for Windows 95 and Windows NT working. > >This implementation supports multiple security channels between two hosts > >or host and security gateway or two security gateways. User can configure > >which application protocol to protect (FTP, TELNET, HTTP...) and what kind > >of algorithm to use. Now it only works with manual key management and only > >in tunnel mode. > > Manual keying is not a problem, but the new I-Ds do require you to support > both tunnel and transport modes, unless your BITS implementation is > destined for use only on security gateways. Stephen, Could you point out where this is stated? The requirements in section 4.5 seem to imply that transport mode is required of all hosts who might communicate under 'Case 1'. While this does not cover the bulk of the traffic between security gateways, it will certainly occur some times. Perhaps at this time someone can also explain to me the benefit of classing an SA as either tunnel or transport. I am still a strong proponent of the old-style (RFC 1825) formatting which allows the IPsec protocol to be more powerful and more generally useful. At one time I proposed > restricting BITS implementatiions to tunnel mode only, but at least one > vendor was implementing transport mode and argued against that, so ... > Also, there is a need to support administrative configuration that may be > more sophisticated than the preceeding paragraph would suggest. I guess I don't see why we should restrict the functionality of an implementation based on the implementation method at all. If the packets emerging from the _box_ don't give any indication of what method was used to encapsulate them, why should we even care? ben From owner-ipsec Thu Jan 22 20:22:43 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA08117 for ipsec-outgoing; Thu, 22 Jan 1998 20:17:49 -0500 (EST) Date: Thu, 22 Jan 1998 20:27:17 -0600 (CST) From: Engineering To: Ben Rogers cc: Stephen Kent , Xuechen Yang , ipsec@tis.com Subject: Re: some issues about IPSec In-Reply-To: <199801221957.OAA14585@carp.morningstar.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk > > Perhaps at this time someone can also explain to me the benefit of > classing an SA as either tunnel or transport. I am still a strong > proponent of the old-style (RFC 1825) formatting which allows the IPsec > protocol to be more powerful and more generally useful. > I really don't see the benefit of transport mode at all from our perspective. None of our customers require it because we can communicate securely peer to peer (This is from a VPCOM (our product) perspective). Also, even going through a third party security gateway, peer to peer can be done. > > I guess I don't see why we should restrict the functionality of an > implementation based on the implementation method at all. If the > packets emerging from the _box_ don't give any indication of what method > was used to encapsulate them, why should we even care? > The questions here are what are the beneifits of transport mode that are not provided in tunnel mode ? Jeffrey Goodwin President/CEO Ashley Laurent, Inc. www.osgroup.com From owner-ipsec Thu Jan 22 20:22:44 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA08149 for ipsec-outgoing; Thu, 22 Jan 1998 20:21:49 -0500 (EST) Date: Thu, 22 Jan 1998 20:31:09 -0600 (CST) From: Engineering To: ipsec@tis.com cc: RHS Linux User , Xuechen Yang Subject: some more issues on IPSEC Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk We were talking to a customer who indicated there may be a draft on dynamic ip address registration for IPSEC remote client applications. Essentially, we are faced with implementing our own proprietary protocol like PPTP does. Does anyone have more information about any RFC's or drafts on this ? Jeffrey Goodwin President/CEO Ashley Laurent, Inc. www.osgroup.com ** Ashley Laurent,Inc. ** Software Development ** Consulting ** * * * * 707 West Avenue, Suite 201 * voice: 512-322-0676 * * Austin, Texas 78701 * fax : 512-322-0680 * * web: http://www.osgroup.com * * Microsoft Solution Provider * Complete Systems Design/Development * * Novell Professional Developer * Systems Software/Device Drivers * From owner-ipsec Fri Jan 23 03:50:29 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id DAA10481 for ipsec-outgoing; Fri, 23 Jan 1998 03:47:52 -0500 (EST) From: Dan McDonald Message-Id: <199801230859.AAA17202@kebe.eng.sun.com> Subject: Re: Security Association Lifetimes in kbytes To: jhwilson@austin.ibm.com (Jackie Wilson) Date: Fri, 23 Jan 1998 00:59:45 -0800 (PST) Cc: ipsec@tis.com In-Reply-To: <199801221754.LAA22814@jhwilson.austin.ibm.com> from "Jackie Wilson" at Jan 22, 98 11:54:44 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk > In order to get consistency in implementations of various > IP Security products, I wanted to ask about implementing > lifetimes in terms of kbytes. How about bytes? (You'll notice PF_KEYv2 uses a uint64_t to count the number of _bytes_ an SA consumes.) > Is it assumed that we use the length field in the IP header? > If so, won't the effect vary depending on IP V4/ IP V6 and > various options that are selected that determine the number > and size of headers and MTU sizes? How would an administrator > know how much to increment the size to account for this type > of overhead? IMHO, and in my code, I count "number of bytes used by the primary algorithm". For ESP, this means the number of bytes I encrypt/decrypt. For AH, this means the number of bytes I feed into the authentication algorithm. > How do we handle overlap to refresh the keys before the > previous SA expires? You'll notice also in PF_KEY that there are two kinds of lifetimes, a _SOFT_ lifetime, and a _HARD_ lifetime. When the soft lifetime expires, an SADB_EXPIRE message goes up. A KMd can consider this a warning to perhaps go negotiate a replacement SA. I dunno if you're using PF_KEY in your implementation, but if you are, it has all of the facilities... you just need to implement the abstraction of soft and hard lifetimes in your SADB. > Is this usually a user-configurable option of some percentage of the > lifetime? Seems success at refreshing the keys would vary depending on > whether the data is bursty or not. See above for one solution. > Can the tunnel expire in the middle of a packet, or do we > implement it on packet boundaries? Do you toss the packet > if the entire packet does not make it in the lifetime? I do toss the packet if the entire packet does not make it in a lifetime. > Would appreciate your feedback. Hope this helps! -- Daniel L. McDonald - Solaris Internet Engineering || MY OPINIONS ARE NOT Mail: danmcd@eng.sun.com, danmcd@kebe.com <*> || NOT NECESSARILY SUN'S! Phone: (650) 786-6815 |"rising falling at force ten WWW: http://www.kebe.com/~danmcd | we twist the world and ride the wind" - Rush From owner-ipsec Fri Jan 23 07:13:28 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA11690 for ipsec-outgoing; Fri, 23 Jan 1998 07:11:53 -0500 (EST) Date: Fri, 23 Jan 1998 12:16:30 +0000 (GMT) From: George Tsirtsis To: Engineering Cc: ipsec@tis.com, RHS Linux User , Xuechen Yang Subject: Re: some more issues on IPSEC In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk On Thu, 22 Jan 1998, Engineering wrote: > > We were talking to a customer who indicated there may be a draft on > dynamic ip address registration for IPSEC remote client applications. > > Essentially, we are faced with implementing our own proprietary protocol > like PPTP does. > > Does anyone have more information about any RFC's or drafts on this ? > If I understand what you are talking about it should be the draft that we recently submitted to the IETF: ftp://ietf.org/internet-drafts/draft-tsirtsis-nat-bypass-00.txt Let me know what you think... > Jeffrey Goodwin > President/CEO > Ashley Laurent, Inc. www.osgroup.com > > ** Ashley Laurent,Inc. ** Software Development ** Consulting ** > * * * > * 707 West Avenue, Suite 201 * voice: 512-322-0676 * > * Austin, Texas 78701 * fax : 512-322-0680 * > * web: http://www.osgroup.com * > * Microsoft Solution Provider * Complete Systems Design/Development * > * Novell Professional Developer * Systems Software/Device Drivers * > > Best regards George ----------------------------- Internet Transport Research | BTLABS | -------------------------------------------------------------------------- Notice: This contribution is the personal view of the author and does not necessarily reflect the technical nor commercial direction of British Telecommunications plc. -------------------------------------------------------------------------- From owner-ipsec Fri Jan 23 07:20:19 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA11727 for ipsec-outgoing; Fri, 23 Jan 1998 07:19:54 -0500 (EST) Date: Fri, 23 Jan 1998 07:32:01 -0500 (EST) Message-Id: <199801231232.HAA18908@carp.morningstar.com> From: Ben Rogers To: Engineering Cc: Ben Rogers , Stephen Kent , Xuechen Yang , ipsec@tis.com Subject: Re: some issues about IPSec In-Reply-To: References: <199801221957.OAA14585@carp.morningstar.com> Reply-To: ben@Ascend.COM (Ben Rogers) Sender: owner-ipsec@ex.tis.com Precedence: bulk osgroup@laurent.osgroup.com writes: > > > > Perhaps at this time someone can also explain to me the benefit of > > classing an SA as either tunnel or transport. I am still a strong > > proponent of the old-style (RFC 1825) formatting which allows the IPsec > > protocol to be more powerful and more generally useful. > > > > I really don't see the benefit of transport mode at all from our > perspective. None of our customers require it because we can communicate > securely peer to peer (This is from a VPCOM (our product) perspective). > Also, even going through a third party security gateway, peer to peer can > be done. It is really not my intention to deny transport mode altogether just because _we_ don't see any need for it. I am intending to question the validity of classifying an SA as tunnel mode or transport mode. The current RFC's truly only define transport mode. Tunnel mode can be inferred by the existence of RFC 1853 (IP-in-IP), or any similar raw tunneling protocol. They make no attempt to restrict the use the SA concept based on some preconceived notion that one header implies the existence of some other header further down the chain. That approach is both more simple to describe and understand, and provides far more functionality. Interoperability issues simply do not exist assuming vendors are capable of correctly understanding the drafts. Their concise language effectively guarantees this. It should be evident that the classification of SA's (both as tunnel/transport, and by the selector concept) in the current drafts is a bad idea simply because of the incredible amount of language required to describe them. We should be looking for something much more simple. > > I guess I don't see why we should restrict the functionality of an > > implementation based on the implementation method at all. If the > > packets emerging from the _box_ don't give any indication of what method > > was used to encapsulate them, why should we even care? > > > > The questions here are what are the beneifits of transport mode that are > not provided in tunnel mode ? No. The question is more along the lines of the following. Supposing my box produces packets correctly in _some_ mode (either tunnel or transport) and puts them out on the line in a manner indistinguishable from your box. Do we care that my implementation lies in the core IP code while yours is a BITS? Should yours be subjected to different criteria than mine, simply because we chose different implementation methods? Why can't we describe the protocol as being generated by a black box, and leave the implementation details to the various implementors? ben From owner-ipsec Fri Jan 23 07:36:19 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA12018 for ipsec-outgoing; Fri, 23 Jan 1998 07:35:53 -0500 (EST) From: "Sumit A. Vakil" To: Subject: Cookie exchange Date: Thu, 22 Jan 1998 22:12:25 -0600 Message-ID: <01bd27b5$1cf62860$1f9a7095@cornholio.my_world.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000A_01BD2782.D25BB860" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.71.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3 Sender: owner-ipsec@ex.tis.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_000A_01BD2782.D25BB860 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable There's something in the ISAKMP draft version 8, that puzzles me: Section 4.3: "Additionally, none of the examples include an initial exchange of = ISAKMP Headers (con- taining initiator and responder cookies) which would provide protection against clogging (see section 2.5.3)." How do I interpret this? Does it meant that before doing, say, an Id = protect exchange, cookies could be exchanged as described in the Oakley = draft? So, the first message in an Id protect exchange could contain = both the intiator and responder cookies? Are there implementations out = there that actually work this way? Thanks, Sumit A. Vakil 3Com, Corporation ------=_NextPart_000_000A_01BD2782.D25BB860 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
There's something in the ISAKMP draft version 8, = that puzzles=20 me:
Section 4.3:
"Additionally, none of = the examples=20 include an initial exchange of ISAKMP Headers (con-
taining initiator = and=20 responder cookies) which would provide protection
against clogging = (see=20 section 2.5.3)." 
 
How do I interpret this?  Does it meant that = before=20 doing, say, an Id protect exchange, cookies could be exchanged as = described in=20 the Oakley draft?  So, the first message in an Id protect exchange = could=20 contain both the intiator and responder cookies?  Are there = implementations=20 out there that actually work this way?
 
Thanks,
 
Sumit A. Vakil
3Com, = Corporation
 
------=_NextPart_000_000A_01BD2782.D25BB860-- From owner-ipsec Fri Jan 23 10:20:56 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA13205 for ipsec-outgoing; Fri, 23 Jan 1998 10:18:53 -0500 (EST) Date: Fri, 23 Jan 1998 10:28:57 -0600 (CST) From: Engineering To: Ben Rogers cc: Stephen Kent , Xuechen Yang , ipsec@tis.com Subject: Re: some issues about IPSec In-Reply-To: <199801231232.HAA18908@carp.morningstar.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk > > > I guess I don't see why we should restrict the functionality of an > > > implementation based on the implementation method at all. If the > > > packets emerging from the _box_ don't give any indication of what method > > > was used to encapsulate them, why should we even care? > > > > > > > The questions here are what are the beneifits of transport mode that are > > not provided in tunnel mode ? > > No. The question is more along the lines of the following. Supposing > my box produces packets correctly in _some_ mode (either tunnel or > transport) and puts them out on the line in a manner indistinguishable > from your box. Do we care that my implementation lies in the core IP > code while yours is a BITS? Should yours be subjected to different > criteria than mine, simply because we chose different implementation > methods? Why can't we describe the protocol as being generated by a > black box, and leave the implementation details to the various > implementors? > First of all I understand your viewpoint, and if it makes sense for embedded solutions, o.k. But benefits and drawbacks are *always* an important consideration. What I'm really looking for here is an answer regarding exactly what the benefit of transport mode is ? Perhaps a user of the transport mode could comment on this for clarfication. Thanks, Jeffrey Goodwin ** Ashley Laurent,Inc. ** Software Development ** Consulting ** * * * * 707 West Avenue, Suite 201 * voice: 512-322-0676 * * Austin, Texas 78701 * fax : 512-322-0680 * * web: http://www.osgroup.com * * Microsoft Solution Provider * Complete Systems Design/Development * * Novell Professional Developer * Systems Software/Device Drivers * From owner-ipsec Fri Jan 23 11:31:26 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA13797 for ipsec-outgoing; Fri, 23 Jan 1998 11:28:54 -0500 (EST) Message-ID: <34C8C7CC.C48@fet.com> Date: Fri, 23 Jan 1998 08:39:40 -0800 From: "Scott G. Kelly" Organization: Furukawa Electric Technologies, Inc. X-Mailer: Mozilla 3.03 (Win95; U) MIME-Version: 1.0 To: Engineering CC: ipsec@tis.com Subject: Re: some issues about IPSec References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Engineering wrote: > > What > I'm really looking for here is an answer regarding exactly what the > benefit of transport mode is ? Perhaps a user of the transport mode could > comment on this for clarfication. > > Thanks, > Jeffrey Goodwin One benefit is that it provides the end-user with the capability to negotiate security association attributes on its own behalf. Perhaps the end-user desires stronger security than the sgw configuration would permit. Perhaps the sgw services so many endusers that the granularity of its SPD is not sufficient to provide for the varied needs of its clients. Perhaps a stronger argument exists in terms of overhead concerns. If the enduser provides its own security service, that's one less (encapsulating) ip header on the packet. Further, it relieves (in the short term) concerns of bottlenecks at sgw's which may not have the processing power and memory to provide the granularity necessary to provide for every client's needs at wireline speeds. From owner-ipsec Fri Jan 23 11:34:05 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA13855 for ipsec-outgoing; Fri, 23 Jan 1998 11:33:55 -0500 (EST) Message-Id: <34C8CAB6.414E6865@zk3.dec.com> Date: Fri, 23 Jan 1998 11:52:06 -0500 From: "Eric L. Wong" X-Mailer: Mozilla 4.04 [en] (WinNT; I) Mime-Version: 1.0 To: ipsec@tis.com Subject: Re: Results of the IPSEC document reading party Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk In the lastest 'draft-ietf-ipsec-isakmp-08.txt' draft, section 2.4 said > While bootstrapping secure channels between systems, ISAKMP cannot assume > the existence of security services, and must provide some protections for > itself. Therefore, ISAKMP considers an ISAKMP Security Association to be > different than other types, and manages ISAKMP SAs itself, in their own > name space. ISAKMP uses the two cookie fields in the ISAKMP header to > identify ISAKMP SAs. The Message ID and SPI fields in the ISAKMP Header ^^^^^^^^^^^^^^ > are used during SA establishment to identify the SA for other security > protocols. The interpretation of these four fields is dependent on the > operation taking place. I do not see a SPI field in the ISAKMP header, shown in section 3.1. The text in the next paragraph seem more correct. I think they should be consistent. > The following table shows the presence or absence of the cookies in the > ISAKMP header, the ISAKMP Header Message ID field, and the SPI field in ^^^^^^^^^^^^^^^^^^^^ > the Proposal payload for various operations. An 'X' in the column means > the value MUST be present. An 'NA' in the column means a value in the > column is Not Applicable to the operation. /eric From owner-ipsec Fri Jan 23 14:24:24 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA15105 for ipsec-outgoing; Fri, 23 Jan 1998 14:21:54 -0500 (EST) X-Lotus-FromDomain: 3COM@3COM-MWGATE From: "Sumit Vakil" To: dennis.glatting@plaintalk.bellevue.wa.us cc: ipsec@tis.com Message-ID: <86256595.005B8692.00@mwgate01.mw.3com.com> Date: Fri, 23 Jan 1998 10:43:29 -0600 Subject: Re: Cookie exchange Mime-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk Sorry about the HTML in my previous e-mail. --------------------------------------------------------------------------- --------------------------------------------------------------------------- -------- There's something in the ISAKMP draft version 8, that puzzles me: Section 4.3: "Additionally, none of the examples include an initial exchange of ISAKMP Headers (containing initiator and responder cookies) which would provide protection against clogging (see section 2.5.3)." How do I interpret this? Does it meant that before doing, say, an Id protect exchange, cookies could be exchanged as described in the Oakley draft? So, the first message in an Id protect exchange could contain both the intiator and responder cookies? Are there implementations out there that actually work this way? Thanks, Sumit A. Vakil 3Com, Corporation dennis.glatting@plaintalk.bellevue.wa.us on 01/23/98 09:41:49 AM Please respond to dennis.glatting@plaintalk.bellevue.wa.us To: Sumit Vakil/MW/US/3Com cc: Subject: Re: Cookie exchange Those of us who do not use HTML based mail readers have no idea what you said. -dpg From owner-ipsec Fri Jan 23 14:29:09 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA15169 for ipsec-outgoing; Fri, 23 Jan 1998 14:28:55 -0500 (EST) From: Dan McDonald Message-Id: <199801231939.LAA25939@kebe.eng.sun.com> Subject: Per-socket policy and ISAKMP To: ipsec@tis.com Date: Fri, 23 Jan 1998 11:39:59 -0800 (PST) Cc: pf_key@inner.net X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Hello IPsec folks! The IPsec crew here at Sun has been wondering something, and we've decided to ask you. Consider the following machine: It supports AH with both HMAC-MD5 and HMAC-SHA-1, and has a global policy that all traffic except ISAKMP requires the use of AH, regardless of algorithm. This global policy information is easily available to ISAKMP so it can negotiate AH services effectively. Now consider two sessions on this machine, both of which want to strengthen global policy by specifying using HMAC-SHA-1 for its AH algorithm. The first is an active session that will invoke ISAKMP as an initiator. Somehow ISAKMP is notified that a session needs a pair of SAs, and in this notification the SHA-1-only requirement is expressed. (In a PF_KEY implementation, this is expressed in the SADB_ACQUIRE message.) The second session, however, is a passive session (e.g. a TCP or UDP listener). Some other machine will send the initial packet, and before that, an ISAKMP request. If some other machine requests HMAC-MD5 for this session, two things can happen. If my ISAKMP is not aware that the particular passive session requires SHA-1, the ISAKMP negotiation will succeed, but packets will be dropped because of per-session policy failure. (I.e. "I got AH with MD5, but I wanted SHA-1. Drop the packet") Some may view this as an access-control feature (if they don't know that algorithm my service wants, they lose), but others may want ISAKMP to reject the request at the key-exchange, to save pain, anguish and suffering. My question is, which is preferable? Do per-socket aberrations to global policy get expressed to key management? Or do they not get expressed? If the answer is the former, BTW, look for a new PF_KEY message that'll express this to a KMd. (It'll be a passive-side counterpart to the ACQUIRE message.) Thanks, Dan From owner-ipsec Fri Jan 23 14:44:08 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA15404 for ipsec-outgoing; Fri, 23 Jan 1998 14:43:56 -0500 (EST) Message-Id: <199801231953.OAA18279@postal.research.att.com> To: Dan McDonald cc: ipsec@tis.com, pf_key@inner.net Subject: Re: Per-socket policy and ISAKMP Date: Fri, 23 Jan 1998 14:53:33 -0500 From: Steve Bellovin Sender: owner-ipsec@ex.tis.com Precedence: bulk > The second session, however, is a passive session (e.g. a TCP or UDP > listener). Some other machine will send the initial packet, and before > that, an ISAKMP request. If some other machine requests HMAC-MD5 for > this session, two things can happen. If my ISAKMP is not aware that > the particular passive session requires SHA-1, the ISAKMP negotiation > will succeed, but packets will be dropped because of per-session policy > failure. (I.e. "I got AH with MD5, but I wanted SHA-1. Drop the > packet") Some may view this as an access-control feature (if they don't > know that algorithm my service wants, they lose), but others may want > ISAKMP to reject the request at the key-exchange, to save pain, anguish > and suffering. > > My question is, which is preferable? Do per-socket aberrations to > global policy get expressed to key management? Or do they not get > expressed? > > If the answer is the former, BTW, look for a new PF_KEY message that'll > express this to a KMd. (It'll be a passive-side counterpart to the > ACQUIRE message.) Very definitely the former. Applications have to be able say what security policy they want on listen()ing sockets. For example, even rlogin and rsh are reasonable protocols between trusted hosts *if* AH is used to verify the identity of the client. From owner-ipsec Fri Jan 23 15:28:10 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA15804 for ipsec-outgoing; Fri, 23 Jan 1998 15:26:10 -0500 (EST) Message-Id: <199801232042.PAA02089@istari.sandelman.ottawa.on.ca> To: ipsec@tis.com Subject: Re: Per-socket policy and ISAKMP In-reply-to: Your message of "Fri, 23 Jan 1998 11:39:59 PST." <199801231939.LAA25939@kebe.eng.sun.com> Date: Fri, 23 Jan 1998 15:42:20 -0500 From: "Michael C. Richardson" Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Dan" == Dan McDonald writes: Dan> and HMAC-SHA-1, and has a global policy that all traffic except Dan> ISAKMP requires the use of AH, regardless of algorithm. This global Dan> policy information is easily available to ISAKMP so it can negotiate Dan> AH services effectively. Okay. Dan> The second session, however, is a passive session (e.g. a TCP or UDP Dan> listener). Some other machine will send the initial packet, and Dan> before that, an ISAKMP request. If some other machine requests Dan> HMAC-MD5 for this session, two things can happen. If my ISAKMP is Dan> not aware that the particular passive session requires SHA-1, the Dan> ISAKMP negotiation will succeed, but packets will be dropped because Dan> of per-session policy failure. (I.e. "I got AH with MD5, but I I think the trick is here: ISAKMP "not aware" --- ISAKMP must be aware of policy. Dan> My question is, which is preferable? Do per-socket aberrations to Dan> global policy get expressed to key management? Or do they not get Dan> expressed? Let's do the reverse: say the machine wants HMAC-SHA1 and the socket requests MD5. Well two things are possible: the system gives it MD5, violating it's own policy, or it takes the "most secure union" of the two. But, maybe the caller is root, and is allowed to override policy? Dan> If the answer is the former, BTW, look for a new PF_KEY message Dan> that'll express this to a KMd. (It'll be a passive-side counterpart Dan> to the ACQUIRE message.) Yes, I think that is a good thing. I didn't realize it wasn't already there. :!mcr!: | Sandelman Software Works Corporation, Ottawa, ON Michael Richardson |Network and security consulting and contract programming Personal: mcr@sandelman.ottawa.on.ca. PGP key available. Corporate: sales@sandelman.ottawa.on.ca. -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQB1AwUBNMkAq9iXVu0RiA21AQG2TQMAnCUiu9UH4Z2QjPxUAmsIEe8Ls7osEJ5Q iM/ELXXtTHScNXWhva9i8KpFNNYzzn0EPZhJCMFHLlfmkGJ+3dIQfy7wmjp2vOFf DoM0RoYc6z8XtYxlEI0d4AGgyNvRSE+T =imkn -----END PGP SIGNATURE----- From owner-ipsec Fri Jan 23 15:37:22 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA15938 for ipsec-outgoing; Fri, 23 Jan 1998 15:37:02 -0500 (EST) Message-ID: <34C90132.BC7F5A32@ire-ma.com> Date: Fri, 23 Jan 1998 15:44:34 -0500 From: Bronislav Kavsan Reply-To: bkavsan@ire-ma.com X-Mailer: Mozilla 4.03 [en] (WinNT; U) MIME-Version: 1.0 To: ipsec@tis.com Subject: Re: some issues about IPSec References: <34C8C7CC.C48@fet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MDaemon-Deliver-To: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Scott G. Kelly wrote: > One benefit is that it provides the end-user with the capability to > negotiate security association attributes on its own behalf. Perhaps the > end-user desires stronger security than the sgw configuration would > permit. Perhaps the sgw services so many endusers that the granularity > of its SPD is not sufficient to provide for the varied needs of its > clients. You can do end-user to end-usr in tunnel mode - therefore I don't buy this argument. > > > Perhaps a stronger argument exists in terms of overhead concerns. If the > enduser provides its own security service, that's one less > (encapsulating) ip header on the packet. Further, it relieves (in the > short term) concerns of bottlenecks at sgw's which may not have the > processing power and memory to provide the granularity necessary to > provide for every client's needs at wireline speeds. I don't buy this argument either - there is no need for double-encapsulation - just establish end-to-end tunnel. -- Bronislav Kavsan IRE Secure Solutions, Inc. 100 Conifer Hill Drive Suite 513 Danvers, MA 01923 voice: 978-739-2384 http://www.ire.com From owner-ipsec Fri Jan 23 15:48:23 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA16077 for ipsec-outgoing; Fri, 23 Jan 1998 15:48:03 -0500 (EST) Message-ID: <34C90478.76EF@fet.com> Date: Fri, 23 Jan 1998 12:58:32 -0800 From: "Scott G. Kelly" Organization: Furukawa Electric Technologies, Inc. X-Mailer: Mozilla 3.03 (Win95; U) MIME-Version: 1.0 To: bkavsan@ire-ma.com CC: ipsec@tis.com Subject: Re: some issues about IPSec References: <34C8C7CC.C48@fet.com> <34C90132.BC7F5A32@ire-ma.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Bronislav Kavsan wrote: > > You can do end-user to end-usr in tunnel mode - therefore I don't buy this > argument. > > I don't buy this argument either - there is no need for double-encapsulation - > just establish end-to-end tunnel. By definition, tunnel mode requires encapsulation. If you are doing end-user to end-user in tunnel mode, this is inefficient because you are wrapping an extra ip header around the packet which supplies no new information. From owner-ipsec Fri Jan 23 17:12:37 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA16739 for ipsec-outgoing; Fri, 23 Jan 1998 17:11:05 -0500 (EST) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: References: <199801221957.OAA14585@carp.morningstar.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 23 Jan 1998 17:21:11 -0500 To: Engineering From: Stephen Kent Subject: Re: some issues about IPSec Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Jeff, Transport mode has less overhead than tunnel mode, because there is no need for a second IP header, and that by itself makes it attractive in many instances. Steve From owner-ipsec Fri Jan 23 18:18:13 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA17164 for ipsec-outgoing; Fri, 23 Jan 1998 18:17:06 -0500 (EST) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <199801231939.LAA25939@kebe.eng.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 23 Jan 1998 18:20:22 -0500 To: Dan McDonald From: Stephen Kent Subject: Re: Per-socket policy and ISAKMP Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Dan, The model I've been assuming calls for the SPD to be consulted when a new SA is created, irrespective of whether one is the initiator or responder. If the intent of the local policy is to require SHA-1 for all SAs, then that should be reflected in the policy database and I would suggest that it result in a failed ISAKMP negotiation, to avoid later discarding of packets. Steve From owner-ipsec Fri Jan 23 18:34:25 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA17293 for ipsec-outgoing; Fri, 23 Jan 1998 18:34:05 -0500 (EST) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <98Jan22.132603est.11651@janus.tor.securecomputing.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 23 Jan 1998 18:46:01 -0500 To: "C. Harald Koch" From: Stephen Kent Subject: Re: Authentication Padding Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Harold, I like your interpretation of the existing text, and hope that's what implementors have been doing. However, I did want to make sure that we we're all on the same wavelength, in response to a question from a WG member who felt that the language was ambiguous. We'll clarify it in the next round of edits, e.g., state that MD5 and SHA-1 are viewed as having a 1-byte block size because of their own padding conventions. Steve From owner-ipsec Fri Jan 23 19:06:26 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA17421 for ipsec-outgoing; Fri, 23 Jan 1998 19:06:08 -0500 (EST) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <199801231232.HAA18908@carp.morningstar.com> References: <199801221957.OAA14585@carp.morningstar.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 23 Jan 1998 19:19:03 -0500 To: ben@Ascend.COM (Ben Rogers) From: Stephen Kent Subject: Re: some issues about IPSec Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Ben, >It is really not my intention to deny transport mode altogether just >because _we_ don't see any need for it. I am intending to question the >validity of classifying an SA as tunnel mode or transport mode. The >current RFC's truly only define transport mode. Tunnel mode can be >inferred by the existence of RFC 1853 (IP-in-IP), or any similar raw >tunneling protocol. They make no attempt to restrict the use the SA >concept based on some preconceived notion that one header implies the >existence of some other header further down the chain. That approach is >both more simple to describe and understand, and provides far more >functionality. Interoperability issues simply do not exist assuming >vendors are capable of correctly understanding the drafts. Their >concise language effectively guarantees this. It should be evident that >the classification of SA's (both as tunnel/transport, and by the >selector concept) in the current drafts is a bad idea simply because of >the incredible amount of language required to describe them. We should >be looking for something much more simple. The notion of tunnel and transport modes has been a part of IPSec for quite some time. Section 3.1 of both AH and ESP define the modes, and I think they do so fairly clearly. We go into a fair amount of detail to try to avoid ambiguity, not because the notions are intrinsically complex. At this late date, I don't think that changing the specs to remove these mode distinctions is a viable option. >No. The question is more along the lines of the following. Supposing >my box produces packets correctly in _some_ mode (either tunnel or >transport) and puts them out on the line in a manner indistinguishable >from your box. Do we care that my implementation lies in the core IP >code while yours is a BITS? Should yours be subjected to different >criteria than mine, simply because we chose different implementation >methods? Why can't we describe the protocol as being generated by a >black box, and leave the implementation details to the various >implementors? The specs are not trying to overly constrain implementations; the intent is to ensure interoperability in more than just the simplest cases, and to provide users with a reasonable degree of functionality. Transport and tunnel modes have different representations on the wire, due to the extra encapsulation in the latter mode, and differenmt requirements with respect to fragmentation. The later differences were adopted because of the problems that can arise in dealing with fragments of encrypted datagrams, support for fine granularity SAs (e.g., based on port fields) etc. Steve From owner-ipsec Fri Jan 23 19:59:01 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA17736 for ipsec-outgoing; Fri, 23 Jan 1998 19:58:05 -0500 (EST) Date: Fri, 23 Jan 1998 20:08:40 -0600 (CST) From: Engineering To: Stephen Kent , Xuechen Yang cc: ipsec@tis.com Subject: Re: some issues about IPSec In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk > Jeff, > > Transport mode has less overhead than tunnel mode, because there is no need > for a second IP header, and that by itself makes it attractive in many > instances. > O.K., so performance is the primary criteria (benefit) ? Tunnel mode is *only* peer to peer, correct ? So the primary issue would be gateway to gateway scenarious, in which all the ESP/AH formatting is done in the gateway only, and not be done by the clients whose clear text traffic is transformed by the gateway ? But for remote access clients (isp dial-ups) I don't see performance as an issue, and don't see the benefit of transport mode outweighing the drawbacks, because. 1) If a remote access client is doing peer to peer, the performance bottleneck isn't in the extra ESP/AH formatting, it's in the internet cloud (the isp hardware and routing process). 2) Probably 100% or close to it (correct me if I'm wrong please) will be running BIST implementations, and for this performance will be *better* using tunnel mode. Given 1 and 2, it seems to be to the detriment of remote access clients to require tunnel mode (again, please correct me if I'm wrong). However, since the specification does not preclude implementations from exclusively utilizing a tunnel mode security policy, I suppose the market place will determine the best solutions by the type of security gateways they implemented for remote access solutions. It just seems like a waste of resources to require the implementation given the analysis contained herein for remote access BIST implementations. Sincerely, Jeffrey Goodwin ** Ashley Laurent,Inc. ** Software Development ** Consulting ** * * * * 707 West Avenue, Suite 201 * voice: 512-322-0676 * * Austin, Texas 78701 * fax : 512-322-0680 * * web: http://www.osgroup.com * * Microsoft Solution Provider * Complete Systems Design/Development * * Novell Professional Developer * Systems Software/Device Drivers * From owner-ipsec Fri Jan 23 21:33:29 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id VAA18285 for ipsec-outgoing; Fri, 23 Jan 1998 21:31:07 -0500 (EST) Message-ID: <01BD282E.9B3F3760.adams@cisco.com> From: Rob Adams Reply-To: "adams@cisco.com" To: "'Engineering'" , Stephen Kent , Xuechen Yang Cc: "ipsec@tis.com" Subject: RE: some issues about IPSec Date: Fri, 23 Jan 1998 18:40:27 -0800 Organization: Cisco Systems X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 Sender: owner-ipsec@ex.tis.com Precedence: bulk I don't think I agree with either of your assertions. The remote client is going to suffer from bandwidth constraints because they can't push out many bytes (slow modems). Those people using slow modems will want to squeeze as much bandwidth out of their modems as possible. Adding another header cuts the number of bytes they can pump. In this case, tunnel mode would be a detriment. The transformation is trivial, the extra bytes are not trivial for 28.8 modem users. I'm not sure why you think 100% of dial in implementations will be bump in the stack. I assume you mean bump in the stack by BIST. I don't agree. And even if that was a common implementation, I'm not sure how a bump in the stack implementation would benefit greatly by only doing tunnel... Can you explain this? -----Original Message----- From: Engineering [SMTP:osgroup@laurent.osgroup.com] Sent: Friday, January 23, 1998 6:09 PM To: Stephen Kent; Xuechen Yang Cc: ipsec@tis.com Subject: Re: some issues about IPSec > Jeff, > > Transport mode has less overhead than tunnel mode, because there is no need > for a second IP header, and that by itself makes it attractive in many > instances. > O.K., so performance is the primary criteria (benefit) ? Tunnel mode is *only* peer to peer, correct ? So the primary issue would be gateway to gateway scenarious, in which all the ESP/AH formatting is done in the gateway only, and not be done by the clients whose clear text traffic is transformed by the gateway ? But for remote access clients (isp dial-ups) I don't see performance as an issue, and don't see the benefit of transport mode outweighing the drawbacks, because. 1) If a remote access client is doing peer to peer, the performance bottleneck isn't in the extra ESP/AH formatting, it's in the internet cloud (the isp hardware and routing process). 2) Probably 100% or close to it (correct me if I'm wrong please) will be running BIST implementations, and for this performance will be *better* using tunnel mode. Given 1 and 2, it seems to be to the detriment of remote access clients to require tunnel mode (again, please correct me if I'm wrong). However, since the specification does not preclude implementations from exclusively utilizing a tunnel mode security policy, I suppose the market place will determine the best solutions by the type of security gateways they implemented for remote access solutions. It just seems like a waste of resources to require the implementation given the analysis contained herein for remote access BIST implementations. Sincerely, Jeffrey Goodwin ** Ashley Laurent,Inc. ** Software Development ** Consulting ** * * * * 707 West Avenue, Suite 201 * voice: 512-322-0676 * * Austin, Texas 78701 * fax : 512-322-0680 * * web: http://www.osgroup.com * * Microsoft Solution Provider * Complete Systems Design/Development * * Novell Professional Developer * Systems Software/Device Drivers * From owner-ipsec Fri Jan 23 23:25:33 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id XAA18788 for ipsec-outgoing; Fri, 23 Jan 1998 23:23:04 -0500 (EST) Message-ID: <34C96E9E.CE120E2F@ire-ma.com> Date: Fri, 23 Jan 1998 23:31:27 -0500 From: Bronislav Kavsan X-Mailer: Mozilla 4.03 [en] (WinNT; U) MIME-Version: 1.0 To: "ipsec@tis.com" Subject: Re: some issues about IPSec References: <01BD282E.9B3F3760.adams@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MDaemon-Deliver-To: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Rob Adams wrote: > .....And even if that was a common implementation, I'm not sure how > a bump in the stack implementation would benefit greatly by only doing > tunnel... Can you explain this? Rob, the transport mode requires encryption before fragmentation - in BITS implementation it translates into creating another IP protocol below TCP/IP protocol for re-assembling fragmented packets, encrypting resulting datagram and fragmenting it again. In the tunnel mode - you can encrypt each fragment separately without re-assembling them into a datagram. Also, the BITS implementation will be very common on Windows platform till Microsoft will implement IPsec in their stack Slava Kavsan IRE From owner-ipsec Sat Jan 24 11:35:56 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA22275 for ipsec-outgoing; Sat, 24 Jan 1998 11:33:04 -0500 (EST) Message-ID: <01BD28A4.7BF45680.adams@cisco.com> From: Rob Adams Reply-To: "adams@cisco.com" To: "'Bronislav Kavsan'" , "ipsec@tis.com" Subject: RE: some issues about IPSec Date: Sat, 24 Jan 1998 08:39:14 -0800 Organization: Cisco Systems X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 Sender: owner-ipsec@ex.tis.com Precedence: bulk This doesn't translate into another tcp under the stack at all. You simply have to be creative about setting MTU.. fake ICMP packets and the like... Which I imagine you'd want to do anyway. You'll end up fragmenting your own packets once you've transformed them anyway. Especially if you're going to do tunnel mode. Seems to me an efficient implementation would make sure that no fragmentation occurs. Especially for the modem case. I still don't see the benefit. -----Original Message----- From: Bronislav Kavsan [SMTP:bkavsan@ire-ma.com] Sent: Friday, January 23, 1998 8:31 PM To: ipsec@tis.com Subject: Re: some issues about IPSec Rob Adams wrote: > .....And even if that was a common implementation, I'm not sure how > a bump in the stack implementation would benefit greatly by only doing > tunnel... Can you explain this? Rob, the transport mode requires encryption before fragmentation - in BITS implementation it translates into creating another IP protocol below TCP/IP protocol for re-assembling fragmented packets, encrypting resulting datagram and fragmenting it again. In the tunnel mode - you can encrypt each fragment separately without re-assembling them into a datagram. Also, the BITS implementation will be very common on Windows platform till Microsoft will implement IPsec in their stack Slava Kavsan IRE From owner-ipsec Sat Jan 24 12:03:31 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA22420 for ipsec-outgoing; Sat, 24 Jan 1998 12:03:06 -0500 (EST) Message-ID: <34CA2072.17B116EA@ire-ma.com> Date: Sat, 24 Jan 1998 12:10:10 -0500 From: Bronislav Kavsan X-Mailer: Mozilla 4.03 [en] (WinNT; U) MIME-Version: 1.0 To: "adams@cisco.com" CC: "ipsec@tis.com" Subject: Re: some issues about IPSec References: <01BD28A4.7BF45680.adams@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MDaemon-Deliver-To: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Rob, You should re-read my mail again. First, I was talking about IP-like layer below TCP/IP satck, not another TCP/IP stack. Second, the MTU setting was discussed here many moons ago - this is not the local matter only - you have to discover MTU end-to-end - and this could very challenging. Third, fragmenting my own packets is easy, but re-assembling someone else's datagrams is a different story. Forth, we are not discussing here benefits of the tunnel mode, but rather questioning advantages of the transport mode over tunnel mode (with admitting that there is an overhead of one IP header worth). Rob Adams wrote: > This doesn't translate into another tcp under the stack at all. > You simply have to be creative about setting MTU.. fake ICMP > packets and the like... Which I imagine you'd want to do anyway. > > You'll end up fragmenting your own packets once you've transformed > them anyway. Especially if you're going to do tunnel mode. > > Seems to me an efficient implementation would make sure that no > fragmentation occurs. Especially for the modem case. > > I still don't see the benefit. > > -----Original Message----- > From: Bronislav Kavsan [SMTP:bkavsan@ire-ma.com] > Sent: Friday, January 23, 1998 8:31 PM > To: ipsec@tis.com > Subject: Re: some issues about IPSec > > Rob Adams wrote: > > > .....And even if that was a common implementation, I'm not sure how > > a bump in the stack implementation would benefit greatly by only doing > > tunnel... Can you explain this? > > Rob, the transport mode requires encryption before fragmentation - in BITS > implementation it translates into creating another IP protocol below TCP/IP > protocol for re-assembling fragmented packets, encrypting resulting datagram and > fragmenting it again. > > In the tunnel mode - you can encrypt each fragment separately without re-assembling > them into a datagram. > > Also, the BITS implementation will be very common on Windows platform till > Microsoft will implement IPsec in their stack > > Slava Kavsan > IRE From owner-ipsec Sat Jan 24 12:30:13 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA22544 for ipsec-outgoing; Sat, 24 Jan 1998 12:30:05 -0500 (EST) Date: Sat, 24 Jan 1998 12:40:14 -0600 (CST) From: Engineering To: Rob Adams cc: Stephen Kent , Xuechen Yang , "ipsec@tis.com" Subject: RE: some issues about IPSec In-Reply-To: <01BD282E.9B3F3760.adams@cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk > I don't think I agree with either of your assertions. > > The remote client is going to suffer from bandwidth constraints because > they can't push out many bytes (slow modems). Those people using > slow modems will want to squeeze as much bandwidth out of their modems > as possible. Adding another header cuts the number of bytes they can pump. > In this case, tunnel mode would be a detriment. The transformation is > trivial, the extra bytes are not trivial for 28.8 modem users. > > I'm not sure why you think 100% of dial in implementations will be bump > in the stack. I assume you mean bump in the stack by BIST. I don't > agree. And even if that was a common implementation, I'm not sure how > a bump in the stack implementation would benefit greatly by only doing > tunnel... Can you explain this? > Please see reference the post by Bronislav Kavsan , on this subject. This succinctly states the issue. BTW, sorry about the typos, I meant BITS... Jeffrey Goodwin ** Ashley Laurent,Inc. ** Software Development ** Consulting ** * * * * 707 West Avenue, Suite 201 * voice: 512-322-0676 * * Austin, Texas 78701 * fax : 512-322-0680 * * web: http://www.osgroup.com * * Microsoft Solution Provider * Complete Systems Design/Development * * Novell Professional Developer * Systems Software/Device Drivers * > > > -----Original Message----- > From: Engineering [SMTP:osgroup@laurent.osgroup.com] > Sent: Friday, January 23, 1998 6:09 PM > To: Stephen Kent; Xuechen Yang > Cc: ipsec@tis.com > Subject: Re: some issues about IPSec > > > > Jeff, > > > > Transport mode has less overhead than tunnel mode, because there is no need > > for a second IP header, and that by itself makes it attractive in many > > instances. > > > > O.K., so performance is the primary criteria (benefit) ? Tunnel mode is > *only* peer to peer, correct ? > > So the primary issue would be gateway to gateway scenarious, in which > all the ESP/AH formatting is done in the gateway only, and not be done > by the clients whose clear text traffic is transformed by the > gateway ? > > But for remote access clients (isp dial-ups) I don't see performance as an > issue, and don't see the benefit of transport mode outweighing the > drawbacks, because. > > 1) If a remote access client is doing peer to peer, the performance > bottleneck isn't in the extra ESP/AH formatting, it's in the internet > cloud (the isp hardware and routing process). > > 2) Probably 100% or close to it (correct me if I'm wrong please) will be > running BIST implementations, and for this performance will be *better* > using tunnel mode. > > Given 1 and 2, it seems to be to the detriment of remote access clients to > require tunnel mode (again, please correct me if I'm wrong). > > However, since the specification does not preclude implementations from > exclusively utilizing a tunnel mode security policy, I suppose the market > place will determine the best solutions by the type of security gateways > they implemented for remote access solutions. It just seems like a waste > of resources to require the implementation given the analysis contained > herein for remote access BIST implementations. > > Sincerely, > Jeffrey Goodwin > > ** Ashley Laurent,Inc. ** Software Development ** Consulting ** > * * * > * 707 West Avenue, Suite 201 * voice: 512-322-0676 * > * Austin, Texas 78701 * fax : 512-322-0680 * > * web: http://www.osgroup.com * > * Microsoft Solution Provider * Complete Systems Design/Development * > * Novell Professional Developer * Systems Software/Device Drivers * > From owner-ipsec Sat Jan 24 12:40:23 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA22615 for ipsec-outgoing; Sat, 24 Jan 1998 12:39:05 -0500 (EST) Date: Sat, 24 Jan 1998 12:48:30 -0600 (CST) From: Engineering To: Rob Adams cc: Stephen Kent , Xuechen Yang , "ipsec@tis.com" Subject: RE: some issues about IPSec In-Reply-To: <01BD282E.9B3F3760.adams@cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk > I don't think I agree with either of your assertions. > > The remote client is going to suffer from bandwidth constraints because > they can't push out many bytes (slow modems). Those people using > slow modems will want to squeeze as much bandwidth out of their modems > as possible. Adding another header cuts the number of bytes they can pump. > In this case, tunnel mode would be a detriment. The transformation is > trivial, the extra bytes are not trivial for 28.8 modem users. > This is not true. Transport mode requires more overhead for fragmentation, and even if it's built directly into the stack the bottleneck isn't in the extra header information, it's in the routing process and hub congestion, not in the 28.8 modem. As a very simple view, when your using your modem, most of the time is not spent with the tx/rx lights flashing constantly (full bandwidth utilization), most of the time is spent waiting for responses (which is where the bottleneck is). Usually ISP bandwidth is oversold, which removes the bottleneck even further from the modem. Jeffrey Goodwin ** Ashley Laurent,Inc. ** Software Development ** Consulting ** * * * * 707 West Avenue, Suite 201 * voice: 512-322-0676 * * Austin, Texas 78701 * fax : 512-322-0680 * * web: http://www.osgroup.com * * Microsoft Solution Provider * Complete Systems Design/Development * * Novell Professional Developer * Systems Software/Device Drivers * From owner-ipsec Sat Jan 24 13:43:14 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA23006 for ipsec-outgoing; Sat, 24 Jan 1998 13:42:05 -0500 (EST) Date: Sat, 24 Jan 1998 12:54:43 -0600 From: jim@smallworks.com (Jim Thompson) Message-Id: <199801241854.MAA06099@beavis.smallworks.com> To: adams@cisco.com, osgroup@laurent.osgroup.com Subject: RE: some issues about IPSec Cc: ipsec@tis.com, kent@bbn.com, xuechen@laurent.osgroup.com Sender: owner-ipsec@ex.tis.com Precedence: bulk > As a very simple view, when your using your modem, most of the time is not > spent with the tx/rx lights flashing constantly (full bandwidth > utilization), most of the time is spent waiting for responses (which is > where the bottleneck is). I respectfully submit that your implementation has problems. I've seen plenty of (BITS) IPSEC implementations that will run (99%) as fast as the transforms will run on any given platform. >Usually ISP bandwidth is oversold, which removes the bottleneck even >further from the modem. Depends entirely on your ISP as to if you notice any effect from this. This subject is also entirely non-ipsec related. Jim From owner-ipsec Sat Jan 24 20:14:35 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA24927 for ipsec-outgoing; Sat, 24 Jan 1998 20:11:06 -0500 (EST) Message-Id: <199801250124.UAA26798@relay.rv.tis.com> Date: Sat, 24 Jan 98 20:18:29 EST From: Charles Lynn To: ipsec@tis.com Subject: Re: some issues about IPSec Sender: owner-ipsec@ex.tis.com Precedence: bulk Folks, >From my perspective, the major benefit of transport mode is that the packet is processed with IP-lyer semantics. I've yet to see a specification for tunneling that: preserves the TTL/hop count semantics, doesn't mess with the Don't Fragment bit, accumulates record route data, sends that packet along the path specified by a source route contained in the (inner IP header) or Routing Header, preserves the IPv6 flow label, etc. Charlie From owner-ipsec Sun Jan 25 17:40:35 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA01320 for ipsec-outgoing; Sun, 25 Jan 1998 17:35:07 -0500 (EST) Date: Sun, 25 Jan 1998 17:46:33 -0500 (EST) X-Sender: kent@po1.bbn.com (Unverified) Message-Id: In-Reply-To: <98Jan22.131405est.11652@janus.tor.securecomputing.com> References: danmcd's message of "Thu, 22 Jan 1998 03:56:11 -0500". <199801220856.AAA08261@kebe.eng.sun.com> <199801220856.AAA08261@kebe.eng.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: "C. Harald Koch" From: Stephen Kent Subject: Re: Padding complexities Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Harold, I don't have all of the previous drafts on my laptop, but the July 97 ESP and AH specs had the same text about padding for authentication. So, we're talking about documents that have been around for about 6 months, and the first comment about this text and the MD5 and SHA-1 padding procedures surfaced just last month. Karen Seo can probably dig up previous versions if you want to track just how long this text has been there. Steve From owner-ipsec Sun Jan 25 17:40:36 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA01321 for ipsec-outgoing; Sun, 25 Jan 1998 17:35:08 -0500 (EST) Date: Sun, 25 Jan 1998 17:46:23 -0500 (EST) X-Sender: kent@po1.bbn.com (Unverified) Message-Id: In-Reply-To: <199801220919.BAA08327@kebe.eng.sun.com> References: <3.0.1.32.19980122122720.006b0964@192.9.200.10> from "rohit" at Jan 22, 98 12:27:20 pm Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Dan McDonald From: Stephen Kent Subject: Re: Manual key management issues Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Dan, Thanks for answering Rohit's question before I got to it! I concur with your explanations. Steve From owner-ipsec Sun Jan 25 17:40:35 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA01329 for ipsec-outgoing; Sun, 25 Jan 1998 17:36:06 -0500 (EST) Date: Sun, 25 Jan 1998 17:47:05 -0500 (EST) X-Sender: kent@po1.bbn.com (Unverified) Message-Id: In-Reply-To: <199801221957.OAA14585@carp.morningstar.com> References: <199801111935.NAA06175@osgroup.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ben@Ascend.COM (Ben Rogers) From: Stephen Kent Subject: Re: some issues about IPSec Cc: "Xuechen Yang" , Sender: owner-ipsec@ex.tis.com Precedence: bulk Ben, >Could you point out where this is stated? The requirements in section >4.5 seem to imply that transport mode is required of all hosts who might >communicate under 'Case 1'. While this does not cover the bulk of the >traffic between security gateways, it will certainly occur some times. Traffic between SGs, or between a host and an SG is always in tunnel mode, so case 1 does not apply. The first text in architecture document to express the requirement for host support of transport mode arises in Section 4.1, which notes "a transport mode SA is a security association between two hosts." Later in this section it states that "Two hosts MAY establish a tunnel mode SA between themselves." These two statement imply a requirement for a host to support both transport and tunnel mode SAs, though I admit it could be more direct in making this point. In Section 4.5, Case 1 requires support for both modes by hosts for host-to-host communication. At the end of this section, there is an attempt to make a concise statement about requirements: "The following combinations of AH and ESP MUST be supported in the indicated contexts: - Cases 1, 3, 4 ... AH in transport mode, ESP in transport mode, AH followed by ESP in transport mode ..." During the reading party in December we did discover some ambiguities between the concise description and the case-by-case descriptions, and agreed to fix these problems, but the text cited here was not one of the cited problem areas. The cited text in 4.1 is in the draft from July, not new in the November draft, as are the diagrams and Case 1 text. In the ESP and AH documents, Section 3.1 describes the applicability of transport mode to hosts (vs. security gateways) and includes an explicit note about the possible complications arising in BITS and BITW host implementations due to possible fragmentation and reassembly problems. The need to provide such support for conformance, despite the potential problems, is explicit here. >Perhaps at this time someone can also explain to me the benefit of >classing an SA as either tunnel or transport. I am still a strong >proponent of the old-style (RFC 1825) formatting which allows the IPsec >protocol to be more powerful and more generally useful. > > At one time I proposed >> restricting BITS implementatiions to tunnel mode only, but at least one >> vendor was implementing transport mode and argued against that, so ... >> Also, there is a need to support administrative configuration that may be >> more sophisticated than the preceeding paragraph would suggest. We have a lot of differences between the old RFCs and the current documents, and there is no claim that the two are generally interoperable, so I don't think that the old RFCs are very relevant to our current discussion. We've changed algorithm details, sequence number processing and location, the order of ESP processing, etc. Also, I'm not sure I understand how blurring the distinction between transport and tunnel mode makes IPsec more powerful and generally useful. Can you cite some instances where you feel this is true? Finally, it occurs to me that perhaps we're focusing on the wrong issue here. My impression is that you have a BITS or BITW imlementation that does not implement transport mode. The motivation for requiring host IPsec implementations to support transport mode is, I think, largely one of bandwidth efficiency, though there may be other reasons too. We want all host implementations to be able to comunicate with one another, and we want to allow the host admin to be able to determine whether transport or tunnel mode is preferred. This leads to a requirement for any host implementation, incluidng BITS and BITW, to implement transport mode. If the WG wants to expempt BITS and BITW iplementations from this requirement, understanding that this will result in some host-to-host communications being forced to tunnel mode where transport mode would have sufficed, then ask he chairs to call for a vote and move on. On the other hand, if folks feel that transport mode support is important for hosts, for efficiency and/or other reasons, and want to maintain the status quo in the specs, let's just move on now. Steve From owner-ipsec Sun Jan 25 18:04:35 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA01507 for ipsec-outgoing; Sun, 25 Jan 1998 18:04:06 -0500 (EST) Date: Sun, 25 Jan 1998 18:15:31 -0500 (EST) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Engineering From: Stephen Kent Subject: Re: some issues about IPSec Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Jeff, >O.K., so performance is the primary criteria (benefit) ? Tunnel mode is >*only* peer to peer, correct ? Hosts MAY use tunnel mode for host-to-host communication. Hosts MUST use tunnel mode for communication with an SG, and SGs must always use tunnel mode. Also, a message from Charlie Lynn provides severa; functional reasons for transport mode over tunnel mode. >So the primary issue would be gateway to gateway scenarious, in which >all the ESP/AH formatting is done in the gateway only, and not be done >by the clients whose clear text traffic is transformed by the >gateway ? As noted above, SGs always use tunnel mode, whether the other end is an other SG or a host. >But for remote access clients (isp dial-ups) I don't see performance as an >issue, and don't see the benefit of transport mode outweighing the >drawbacks, because. I would think that dialup access is a context where the extra bandwidth IS an issue and I see later traffic on that topic shows some other folks agree. >1) If a remote access client is doing peer to peer, the performance >bottleneck isn't in the extra ESP/AH formatting, it's in the internet >cloud (the isp hardware and routing process). Not sure my experience agrees with that characterization. It varies. >2) Probably 100% or close to it (correct me if I'm wrong please) will be >running BIST implementations, and for this performance will be *better* >using tunnel mode. MS is planning to release a native implementation in NT 5, but for now BITS is certainly the way to go for most machines. Also, Sun has had earlier IPsec versions in Solaris for a while. As a Mac user, I'll take whatever I can get! >Given 1 and 2, it seems to be to the detriment of remote access clients to >require tunnel mode (again, please correct me if I'm wrong). A remote access client must implement tunnel mode in order to communuicate with a SG, but not for host-to-host communication. I thought your complaint was about transport mode, right? >However, since the specification does not preclude implementations from >exclusively utilizing a tunnel mode security policy, I suppose the market >place will determine the best solutions by the type of security gateways >they implemented for remote access solutions. It just seems like a waste >of resources to require the implementation given the analysis contained >herein for remote access BIST implementations. Again, I'm confused a bit by your last comments, vs. earlier ones. Tunnel mode will be required for communication with an SG. Frankly, I expect most early use of IPsec will fall into two categories: SG-to-SG and remote user to SG. In both cases, tunnel mode is required, not transport. However, we're been writing the specs not just for the more likely initial cases, but for the general case, whenever we could figure out how to do that. Steve From owner-ipsec Sun Jan 25 19:51:04 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA01992 for ipsec-outgoing; Sun, 25 Jan 1998 19:50:05 -0500 (EST) From: "Alexei V. Vopilov" To: "IPsec MailList" Subject: locating a Security Gateway Date: Mon, 26 Jan 1998 04:01:58 +0300 Message-ID: <01bd29f6$00abe1c0$db253ac3@ppalx> MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.71.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3 Sender: owner-ipsec@ex.tis.com Precedence: bulk What is the status of subj problem? Is there any draft or author working on solving the SG location problem under IPsec/ISAKMP? Thank you, --- Alexei From owner-ipsec Sun Jan 25 21:55:15 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id VAA02738 for ipsec-outgoing; Sun, 25 Jan 1998 21:53:06 -0500 (EST) Message-Id: <199801260306.TAA25026@dharkins-ss20.cisco.com> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: "Alexei V. Vopilov" Cc: "IPsec MailList" Subject: Re: locating a Security Gateway In-Reply-To: Your message of "Mon, 26 Jan 1998 04:01:58 +0300." <01bd29f6$00abe1c0$db253ac3@ppalx> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 25 Jan 1998 19:06:00 -0800 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk Check out RFC2230, "Key Exchange Delegation Record for the DNS". Dan. > What is the status of subj problem? > Is there any draft or author working on > solving the SG location problem under IPsec/ISAKMP? From owner-ipsec Mon Jan 26 07:56:51 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA06317 for ipsec-outgoing; Mon, 26 Jan 1998 07:54:06 -0500 (EST) From: Mohan.Parthasarathy@Eng.Sun.Com (Mohan Parthasarathy) Message-Id: <199801232235.OAA03000@ahiri.eng.sun.com> Subject: Re: Per-socket policy and ISAKMP To: owner-ipsec@tis.com (Michael C. Richardson) Date: Fri, 23 Jan 1998 14:35:02 -0800 (PST) Cc: ipsec@tis.com In-Reply-To: <199801232042.PAA02089@istari.sandelman.ottawa.on.ca> from "Michael C. Richardson" at Jan 23, 98 03:42:20 pm X-Mailer: ELM [version 2.4 PL21] Content-Type: text Sender: owner-ipsec@ex.tis.com Precedence: bulk > > Let's do the reverse: say the machine wants HMAC-SHA1 and the socket > requests MD5. Well two things are possible: the system gives it MD5, > violating it's own policy, or it takes the "most secure union" of the two. > But, maybe the caller is root, and is allowed to override policy? > Perhaps, there can be a tuneable - a ndd variable which can decide whether global policy should override local policy or not. May be the implementation might override depending on the strength (assume some definition of strength) of the per-socket policy and global policy. So, can this affect the application (in any way) which has asked a specific policy and the system overrides with global policy ? -mohan From owner-ipsec Mon Jan 26 08:03:25 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA06492 for ipsec-outgoing; Mon, 26 Jan 1998 08:03:07 -0500 (EST) Date: Mon, 26 Jan 1998 08:14:57 -0500 From: "Freedman, Jerome" Subject: RE: locating a Security Gateway To: "Alexei V. Vopilov" Cc: ipsec@tis.com Message-id: <8D3B7E46799CCF118D9D00805FE28A1E02E10DA2@ndhm06.ndhm.gtegsc.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-type: text/plain Content-transfer-encoding: 7BIT X-Priority: 3 Sender: owner-ipsec@ex.tis.com Precedence: bulk We have a home grown protocol ( Remote Encryptor Configuration Exchange Protocol - RECIPe) we intend to use in our next product. It is based on SDNS KMP which we used in a previous product. I ran it by Bob Moskowitz for the VPN BOF in Washington. I was scheduled to present but I didn't. The protocol is not perfect by any means but I would be happy to share it if there is interest. Jerry Freedman,Jr GTE Gov't Systems 781-455-2451 > ---------- > From: Alexei V. Vopilov[SMTP:alx@elnet.msk.ru] > Sent: Sunday, January 25, 1998 8:01 PM > To: IPsec MailList > Subject: locating a Security Gateway > > What is the status of subj problem? > Is there any draft or author working on > solving the SG location problem under IPsec/ISAKMP? > > Thank you, > --- > Alexei > From owner-ipsec Mon Jan 26 08:38:35 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA06822 for ipsec-outgoing; Mon, 26 Jan 1998 08:38:07 -0500 (EST) Message-Id: <199801261401.GAA22382@relay.la.tis.com> Comments: Authenticated sender is From: "Elfed T. Weaver" Organization: DERA To: ipsec@tis.com Date: Mon, 26 Jan 1998 13:47:53 +0000 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: some issues about IPSec In-reply-to: References: X-mailer: Pegasus Mail for Win32 (v2.54) Sender: owner-ipsec@ex.tis.com Precedence: bulk A couple of questions. Security: Does policy require me to protect my data As-Soon-As-Possible ? Efficency: Is it more efficient to apply my cryptographic transform to as large a chunk of data as possible ? Do I wish to ensure all packets arrive before applying my cryptographic transform ? Do I wish to minimise the number of bits on the wire ? If the answer to any of the above is yes, then it seems reasonable that Transport mode would be required on hosts. So, if we want to ensure interoperability Transport mode needs to be mandated for hosts. Elfed **************************************************** "The views expressed above are entirely those of the writer and do not represent the views, policy or understanding of any other person or official body." Elfed T. Weaver DERA Malvern UK weaver@hydra.dra.hmg.gb **************************************************** From owner-ipsec Mon Jan 26 09:51:02 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA07549 for ipsec-outgoing; Mon, 26 Jan 1998 09:50:10 -0500 (EST) From: "Alexei V. Vopilov" To: "Freedman, Jerome" Cc: Subject: Re: locating a Security Gateway Date: Mon, 26 Jan 1998 18:00:44 +0300 Message-ID: <01bd2a6b$2d7bd780$LocalHost@ppalx> MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.71.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by portal.ex.tis.com id JAA07543 Sender: owner-ipsec@ex.tis.com Precedence: bulk Could you point me on any draft regarding to your RECIPe? The request above actually means that interest does exist on mentioned topic ;-) Thank you. --- Alexei V. Vopilov (alx@elnet.msk.ru), +7(095)5367694 Software Architecture&Development Consultant. --- -----Original Message----- From: Freedman, Jerome To: Alexei V. Vopilov Cc: ipsec@tis.com Date: 26 ÑÎ×ÁÒÑ 1998 Ç. 16:15 Subject: RE: locating a Security Gateway We have a home grown protocol ( Remote Encryptor Configuration Exchange Protocol - RECIPe) we intend to use in our next product. It is based on SDNS KMP which we used in a previous product. I ran it by Bob Moskowitz for the VPN BOF in Washington. I was scheduled to present but I didn't. The protocol is not perfect by any means but I would be happy to share it if there is interest. Jerry Freedman,Jr GTE Gov't Systems 781-455-2451 > ---------- > From: Alexei V. Vopilov[SMTP:alx@elnet.msk.ru] > Sent: Sunday, January 25, 1998 8:01 PM > To: IPsec MailList > Subject: locating a Security Gateway > > What is the status of subj problem? > Is there any draft or author working on > solving the SG location problem under IPsec/ISAKMP? > > Thank you, > --- > Alexei > From owner-ipsec Mon Jan 26 10:20:14 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA07826 for ipsec-outgoing; Mon, 26 Jan 1998 10:19:15 -0500 (EST) Date: Mon, 26 Jan 1998 10:28:48 -0600 (CST) From: Engineering To: Stephen Kent cc: ipsec@tis.com Subject: Re: some issues about IPSec In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk > > >So the primary issue would be gateway to gateway scenarious, in which > >all the ESP/AH formatting is done in the gateway only, and not be done > >by the clients whose clear text traffic is transformed by the > >gateway ? > > As noted above, SGs always use tunnel mode, whether the other end is an > other SG or a host. > Thanks for the clarification. > >But for remote access clients (isp dial-ups) I don't see performance as an > >issue, and don't see the benefit of transport mode outweighing the > >drawbacks, because. > > I would think that dialup access is a context where the extra bandwidth IS > an issue and I see later traffic on that topic shows some other folks agree. > O.K., thanks for the input. We're going to go ahead and special case transport mode so our product is IPSEC compliant, even though hardly anyone will likely use that feature based on customer feedback. > > >However, since the specification does not preclude implementations from > >exclusively utilizing a tunnel mode security policy, I suppose the market > >place will determine the best solutions by the type of security gateways > >they implemented for remote access solutions. It just seems like a waste > >of resources to require the implementation given the analysis contained > >herein for remote access BIST implementations. > > Again, I'm confused a bit by your last comments, vs. earlier ones. Tunnel > mode will be required for communication with an SG. This was what I needed clarification, as stated above. >Frankly, I expect most > early use of IPsec will fall into two categories: SG-to-SG and remote user > to SG. In both cases, tunnel mode is required, not transport. However, > we're been writing the specs not just for the more likely initial cases, > but for the general case, whenever we could figure out how to do that. > O.K., we'll comply, even though it's low on our customers priority list. Sincerey, Jeffrey Goodwin ** Ashley Laurent,Inc. ** Software Development ** Consulting ** * * * * 707 West Avenue, Suite 201 * voice: 512-322-0676 * * Austin, Texas 78701 * fax : 512-322-0680 * * web: http://www.osgroup.com * * Microsoft Solution Provider * Complete Systems Design/Development * * Novell Professional Developer * Systems Software/Device Drivers * From owner-ipsec Mon Jan 26 11:42:37 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA08627 for ipsec-outgoing; Mon, 26 Jan 1998 11:41:21 -0500 (EST) Message-Id: <98Jan26.115316est.11653@janus.tor.securecomputing.com> To: Charles Lynn cc: ipsec@tis.com Subject: Re: some issues about IPSec References: <199801250124.UAA26798@relay.rv.tis.com> In-reply-to: Your message of "Sat, 24 Jan 1998 20:18:29 -0500". <199801250124.UAA26798@relay.rv.tis.com> From: "C. Harald Koch" Date: Mon, 26 Jan 1998 11:52:49 -0500 Sender: owner-ipsec@ex.tis.com Precedence: bulk In message <199801250124.UAA26798@relay.rv.tis.com>, Charles Lynn writes: > Folks, > > From my perspective, the major benefit of transport mode is that the > packet is processed with IP-lyer semantics. I've yet to see a > specification for tunneling that: > preserves the TTL/hop count semantics, > doesn't mess with the Don't Fragment bit, > accumulates record route data, > sends that packet along the path specified by a source route > contained in the (inner IP header) or Routing Header, > preserves the IPv6 flow label, etc. You're talking about different tunnel-mode semantics than most people, probably because of a Mobile-IP background. The IP-in-IP tunnels *I* want to see should look like (lossy) layer 1/2 links. The Internet should be invisible, and the tunnel should look like a single L2 network link to IP. One of the justifications for IPsec tunnel mode is that it hides all of the information in the inner packet (particularly IP options like record-route and source-route) from an outside observer. Thus: tunnel doesn't link inner/outer TTLs Path MTU should be supported, but copy DF bit is not required. no record route or source route copying from inside to outside. I understand that Mobile-IP *wants* to see the underlying network; IPsec does not, and also doesn't want the inner packet visible in any way. (IMHO, naturally :-) -- Harald Koch From owner-ipsec Mon Jan 26 12:44:13 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA09012 for ipsec-outgoing; Mon, 26 Jan 1998 12:42:20 -0500 (EST) Message-Id: <199801261752.MAA20371@relay.hq.tis.com> Date: Mon, 26 Jan 98 12:51:55 EST From: Charles Lynn To: "C. Harald Koch" cc: Charles Lynn , ipsec@tis.com Subject: Re: some issues about IPSec Sender: owner-ipsec@ex.tis.com Precedence: bulk Harald, > You're talking about different tunnel-mode semantics than most people, Maybe I was not sufficiently clear. My message was intended to give reasons why Transport Mode is needed, not about the relative merits of the different tunneling schemes. I think that trying to get a tunnel to emulate the IP layer, in all its glory, is very hard. But I think that IPSec should serve all the communities that need real security services, not just those wanting a VPN, or mobility, or ... In addition, IPSec should not be so restrictive that it makes it harder for the routing subsystem to evolve in ways that inevitably will be needed to scale to a truly global Internet. The number of folk working in the area is so large today that I find it hard to keep track of all that is happening. Have you heard about the suggestions to help the scaling and autoconfiguration problem by having routers rewrite IP addresses as the packets pass by? Consider what will happen to end-to-end authentication then. AH may turn out to be a major denial of service attack. (At the moment, ESP authentication, either with or without confidentiality, could be used to get around the problem, but I do not think that the infrastructure to decide when AH will work and when ESP would be needed is there.) Lots of things for us to consider in IPSecond. Charlie From owner-ipsec Mon Jan 26 12:56:01 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA09095 for ipsec-outgoing; Mon, 26 Jan 1998 12:55:19 -0500 (EST) Date: Mon, 26 Jan 1998 13:07:28 -0500 From: "Freedman, Jerome" Subject: RE: locating a Security Gateway To: "Alexei V. Vopilov" Cc: ipsec@tis.com Message-id: <8D3B7E46799CCF118D9D00805FE28A1E02E20BA3@ndhm06.ndhm.gtegsc.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-type: text/plain; charset="iso-8859-1" Content-transfer-encoding: 7BIT X-Priority: 3 Sender: owner-ipsec@ex.tis.com Precedence: bulk In response to Alexei Vopilov, this is our security gateway location protocol. It is currently included in a product we are building. The basic concept came from SDNS KMP which we used in an earlier product. This particular feature was in the narrative part of the KMP spec but, for some reason - maybe funds ran out, was garbeled in the accompanying state machine. We pieced it together from the narrative description and it work{s,ed} fine. Since we were going to SAMP and ISAKMP, neither of which had this facility we broke it out into RECIP. I have included it whole since it is not that big and I have had trouble including it as an attachment before. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ +++++++++++++++ Remote Encryptor Configuration Information Protocol (RECIPe) January 26, 1997 J. Freedman, J. Evans, N. ONeil, C. Limoges 1 Introduction The Remote Encryptor Configuration Information Protocol (RECIPe) provides a simple, low bandwidth mechanism for conveying configuration information between Inline Network Encryptors (INEs) on Internet Protocol (IP) networks. The information exchanged via RECIPe is used to establish and maintain IP-based Security Associations (SAs) between INEs. RECIPe allows an SA initiator INE to determine the IP address of an intended SA responder INE when the SA initiator INE only knows the IP address of the intended INE-protected host. This feature is referred to as Probe/Tryme. The RECIPe message sent by the SA initiator is called a Probe and the message returned by the SA responder in reply is called a Tryme, since Tryme is the historical term used for the feature by the Secure Data Network System (SDNS) Key Management Protocol (KMP). RECIPe also allows an SA responder INE to let an SA initiator INE know when an SA does not exist. This feature is referred to as Nokey, since that is the historical term used for the feature by the SDNS KMP. Nokey messages are generated by the SA responder without any previous RECIPe message being received from an initiator. 2 Protocol Message Formats RECIPe uses a single message format for all messages. This format is illustrated below. Note that all fields are aligned on 32 bit boundaries. All unused fields in any RECIPe message are always set to zeros. Table 2-1. RECIPe Message Format Field Octet Number (Size) Version 1-4 (4 octets) Length 5-8 (4 octets) Security Parameters Index (SPI) 9-12 (4 octets) Status 13-16 (4 octets) Source INE IP Address 17-20 (4 octets) Source INE Identifier 21-24 (4 octets) Target Host IP Address 25-28 (4 octets) Target INE IP Address 29-32 (4 octets) Target INE Identifier 33-36 (4 octets) Each field of the RECIPe message format is described below: a) Version: RECIPe version number, currently always defined as 1. b) Length: Length of the RECIPe message, in 32 bit words. c) SPI: Security Parameters Index identifies the SA. Set by SA responder for Tryme. d) Status: 0 indicates no special status, 1 indicates Nokey, and 2 indicates that traffic cannot be delivered to the Target Host. Set to 0 by SA initiator or responder for Probe. Set to 1 or 2 by SA responder for Nokey. e) Source INE IP Address: IP address of the INE establishing the SA. Set by SA initiator for Probe. Set by SA responder for Nokey. f) Source INE Identifier: Additional 32 bits of information to identify the source INE (Optional). Set by SA initiator for Probe. g) Target Host IP Address: IP address of the intended INE-protected host. Set by SA initiator for Probe. h) Target INE IP Address: IP address of the INE fronting the Target Host. Set by SA responder for Tryme and Nokey. i) Target INE Identifier: Additional 32 bits of information used to identify the target INE (Optional). Set by SA responder for Tryme and Nokey. 3 Protocol Processing Below is a description of the processing involved for both the Probe/Tryme and Nokey functions of RECIPe. 3.1 SA Initiator An SA initiator preparing to establish an SA performs the following processing: 1. SA initiator sends a RECIPe Probe message to the Target Host IP Address, populating the fields of the message as follows: a) Version = 1. b) SPI = 0. c) Status = 0. d) Source INE IP Address = IP address of the INE establishing the SA (the SA initiator). e) Source INE Identifier = 32 bits of additional information (if used). f) Target Host IP Address = IP address of the intended INE-protected host. 2. If no Tryme message is received, the RECIPe Probe message may be repeated based on locally-defined criteria (e.g., if Plaintext (PT) traffic is still being received for the Target Host IP Address). 3. If a Tryme message is received, the SA initiator matches up the Target Host IP Address with the previously sent RECIPe Probe message(s) based on locally-defined criteria (e.g., a queue of outstanding Probe requests). If multiple Tryme messages are received, the first Tryme message received should be acted upon for SA establishment. 4. If a Nokey message is received, then the SA initiator should perform the following processing: a) If the Status = 1 then the SA initiator should delete the SA identified in the Nokey message. b) If the Status = 2, then the Target Host IP Address identified in the Nokey message should be dis-associated from the SA identified in the Nokey message based on locally-defined criteria. 3.2 SA Responder An SA responder performs the following processing upon receipt of a Probe message (Note that the SA responder is assumed to be the intended INE since it received the RECIPe Probe message): 1. The SA responder sends a Tryme message to the SA initiator with all fields the same as the Probe except for the Target INE IP address and Target INE Identifier (if used), which are set to the SA responder IP address and identifier, respectively. An SA responder performs the following processing when IP traffic associated with a specific SA is received that cannot be decrypted by the SA responder: 1. If the SA does not exist, then the SA responder sends a Nokey message to the SA initiator, populating the message with the following fields: a) Version = 1. b) SPI = SPI associated with the SA the traffic was received for. c) Status = 1. d) Source INE IP Address = IP address of the INE establishing the SA (the SA initiator). e) Target INE IP Address = SA responder IP address. f) Target INE Identifier = 32 bits of additional information (if used). An SA responder performs the following processing when decrypted IP traffic cannot be delivered to an intended Target Host IP Address. 2. If the SPI exists, but decrypted traffic cannot be delivered to the Target Host IP Address associated with the SA, then the SA responder sends a Nokey message to the SA initiator, populating the message with the following fields: a) Version = 1. b) SPI = SPI associated with the SA the traffic was received for. c) Status = 2. d) Source INE IP Address = IP address of the INE establishing the SA (the SA initiator). e) Target Host IP Address = Destination IP address of decrypted traffic. f) Target INE IP Address = SA responder IP address. g) Target INE Identifier = 32 bits of additional information (if used). From owner-ipsec Mon Jan 26 14:57:46 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA10210 for ipsec-outgoing; Mon, 26 Jan 1998 14:56:23 -0500 (EST) Message-ID: <34CCEC09.3B7BED1B@ire-ma.com> Date: Mon, 26 Jan 1998 15:03:21 -0500 From: Bronislav Kavsan Reply-To: bkavsan@ire-ma.com X-Mailer: Mozilla 4.03 [en] (WinNT; U) MIME-Version: 1.0 To: Charles Lynn CC: "C. Harald Koch" , ipsec@tis.com Subject: Re: some issues about IPSec References: <199801261752.MAA20371@relay.hq.tis.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MDaemon-Deliver-To: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk ...talking about denial-of-service attack on the ISAKMP/IPsec - I came up with very easy one. ISAKMP main mode authenticates users in it's third exchange, after very hard work of negotiation and doing Diffie-Hellman (exponentiation!!) and deriving secret keys during previous two exchanges. And only in the third exchange, after verifying signatures, CRL and certificate chain (more exponentiation!!) my fake ISAKMP session will be rejected. This attack is especially possible against SGWs that will authenticate "road warriers" - for whom SGWs will not have permanent IP addresses in its SPD and will rely on the main mode exchange to authenticate them before rejecting the session. Charles Lynn wrote: > Harald, > > > You're talking about different tunnel-mode semantics than most people, > > Maybe I was not sufficiently clear. My message was intended to give > reasons why Transport Mode is needed, not about the relative merits of > the different tunneling schemes. I think that trying to get a tunnel > to emulate the IP layer, in all its glory, is very hard. But I think > that IPSec should serve all the communities that need real security > services, not just those wanting a VPN, or mobility, or ... > > In addition, IPSec should not be so restrictive that it makes it > harder for the routing subsystem to evolve in ways that inevitably > will be needed to scale to a truly global Internet. The number of > folk working in the area is so large today that I find it hard to keep > track of all that is happening. Have you heard about the suggestions > to help the scaling and autoconfiguration problem by having routers > rewrite IP addresses as the packets pass by? Consider what will > happen to end-to-end authentication then. AH may turn out to be a > major denial of service attack. (At the moment, ESP authentication, > either with or without confidentiality, could be used to get around > the problem, but I do not think that the infrastructure to decide when > AH will work and when ESP would be needed is there.) > > Lots of things for us to consider in IPSecond. > > Charlie -- Bronislav Kavsan IRE Secure Solutions, Inc. 100 Conifer Hill Drive Suite 513 Danvers, MA 01923 voice: 978-739-2384 http://www.ire.com From owner-ipsec Mon Jan 26 15:18:36 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA10407 for ipsec-outgoing; Mon, 26 Jan 1998 15:18:24 -0500 (EST) Message-Id: <98Jan26.152959est.11659@janus.tor.securecomputing.com> To: Charles Lynn cc: ipsec@tis.com Subject: Re: some issues about IPSec References: <199801261752.MAA20371@relay.hq.tis.com> In-reply-to: clynn's message of "Mon, 26 Jan 1998 12:51:55 -0500". <199801261752.MAA20371@relay.hq.tis.com> From: "C. Harald Koch" X-uri: X-Face: )@F:jK?*}hv!eJ}*r*0DD"k8x1.d#i>7`ETe2;hSD2T!:Fh#wu`0pW7lO|Dfe'AbyNy[\Pw z'.bAtgTM!+iq2$yXiv4gf<:D*rZ-|f$\YQi7"D"=CG!JB?[^_7v>8Mm;z:NJ7pss)l__Cw+.>xUJ) did@Pr9 Date: Mon, 26 Jan 1998 15:29:44 -0500 Sender: owner-ipsec@ex.tis.com Precedence: bulk In message <199801261752.MAA20371@relay.hq.tis.com>, Charles Lynn writes: > > Maybe I was not sufficiently clear. My message was intended to give > reasons why Transport Mode is needed, not about the relative merits of > the different tunneling schemes. Oops. Sorry; hot button there. The "tunnelling is all wrong!" statement came up in the past, and I interpreted your remarks as a repetition of that sentiment. > Have you heard about the suggestions > to help the scaling and autoconfiguration problem by having routers > rewrite IP addresses as the packets pass by? I've heard such things. Most of the routing people I trust haven't mentioned support for this idea, so I doubt it will fly. Also, there are many protocols being actively deployed these days that embed IP addresses in packets (much to the annoyance of us firewall developers). Anything that re-writes addresses on the fly is going to break some popular but undocumented internet phone or video conferencing protocol, and millions of users will scream. > Lots of things for us to consider in IPSecond. Agreed! -- Harald From owner-ipsec Mon Jan 26 15:31:06 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA10505 for ipsec-outgoing; Mon, 26 Jan 1998 15:30:23 -0500 (EST) Message-Id: <199801262041.MAA26266@dharkins-ss20.cisco.com> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: bkavsan@ire-ma.com Cc: Charles Lynn , "C. Harald Koch" , ipsec@tis.com Subject: Re: some issues about IPSec In-Reply-To: Your message of "Mon, 26 Jan 1998 15:03:21 EST." <34CCEC09.3B7BED1B@ire-ma.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 26 Jan 1998 12:41:57 -0800 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: bulk Nothing new here; this had been discussed in the past. Since the responder won't begin exponentiation until receipt of the 2nd message (which contains his cookie which he passed in the 1st) he at least knows there's a peer at a particular IP address which "speaks" ISAKMP. Therefore the SGW won't do the actual exponentiation if barraged with hundreds of ISAKMP packets with spoofed source addresses. The attacker has to receive the 1st response from the SGW and reply properly to get the SGW to exponentiate. It might be easy to track down such an attacker in this situation. I'm not saying this attack isn't possible, just that it isn't _very easy_ to get a SGW to do exponentiations in a sufficient number to consititute a serious attack. Dan. > ...talking about denial-of-service attack on the ISAKMP/IPsec - I came up > with very easy one. > > ISAKMP main mode authenticates users in it's third exchange, after very hard > work of negotiation and doing Diffie-Hellman (exponentiation!!) and deriving > secret keys during previous two exchanges. > > And only in the third exchange, after verifying signatures, CRL and > certificate chain (more exponentiation!!) my fake ISAKMP session will be > rejected. > > This attack is especially possible against SGWs that will authenticate "road > warriers" - for whom SGWs will not have permanent IP addresses in its SPD > and will rely on the main mode exchange to authenticate them before > rejecting the session. From owner-ipsec Mon Jan 26 15:38:30 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA10598 for ipsec-outgoing; Mon, 26 Jan 1998 15:38:23 -0500 (EST) Message-Id: <199801262047.PAA05694@postal.research.att.com> To: "C. Harald Koch" cc: Charles Lynn , ipsec@tis.com Subject: Re: some issues about IPSec Date: Mon, 26 Jan 1998 15:47:17 -0500 From: Steve Bellovin Sender: owner-ipsec@ex.tis.com Precedence: bulk > > Have you heard about the suggestions > > to help the scaling and autoconfiguration problem by having routers > > rewrite IP addresses as the packets pass by? > > I've heard such things. Most of the routing people I trust haven't mentioned > support for this idea, so I doubt it will fly. Also, there are many protocols > being actively deployed these days that embed IP addresses in packets (much > to the annoyance of us firewall developers). Anything that re-writes > addresses on the fly is going to break some popular but undocumented > internet phone or video conferencing protocol, and millions of users will > scream. This is primarily an IPv6 idea. And if it "passed", it would apply to the high-order 64 bits (or thereabouts) of an address; the low-order 64 bits would remain untouched. From owner-ipsec Mon Jan 26 17:14:59 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA11655 for ipsec-outgoing; Mon, 26 Jan 1998 17:12:25 -0500 (EST) Message-ID: <34CCFDEB.8E36639D@tiac.net> Date: Mon, 26 Jan 1998 16:19:39 -0500 From: Michael Giniger X-Mailer: Mozilla 4.01 [en] (Win95; I) MIME-Version: 1.0 To: ipsec@tis.com Subject: ANX interoperability X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi I would be interested in obtaining information concerning participation in ANX interoperability testing. In order for a product to participate in the ANX interoperability tests what is the set of internet drafts which must be implemented? for example esp v2? isakmp v8? isakmp/oakley v5? etc. What individual may I contact for further information on this subject including the procedures for partaking in the interoperability tests? Thank you very much Sincerely Michael Giniger From owner-ipsec Mon Jan 26 17:18:36 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA11683 for ipsec-outgoing; Mon, 26 Jan 1998 17:18:26 -0500 (EST) Date: Mon, 26 Jan 1998 17:30:00 -0500 Message-Id: <199801262230.RAA05131@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: Daniel Harkins Cc: bkavsan@ire-ma.com, Charles Lynn , "C. Harald Koch" , ipsec@tis.com In-Reply-To: Daniel Harkins's message of Mon, 26 Jan 1998 12:41:57 -0800, <199801262041.MAA26266@dharkins-ss20.cisco.com> Subject: Re: some issues about IPSec Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-ipsec@ex.tis.com Precedence: bulk Date: Mon, 26 Jan 1998 12:41:57 -0800 From: Daniel Harkins Since the responder won't begin exponentiation until receipt of the 2nd message (which contains his cookie which he passed in the 1st) he at least knows there's a peer at a particular IP address which "speaks" ISAKMP. Therefore the SGW won't do the actual exponentiation if barraged with hundreds of ISAKMP packets with spoofed source addresses. The attacker has to receive the 1st response from the SGW and reply properly to get the SGW to exponentiate. It might be easy to track down such an attacker in this situation. Just to amplify a particular point which Dan made here. The key here is that it's much harder to do a denial of service attack without revealing your IP address, which presumably would make it much easier to trace things back to you. At this point, one can use out-of-band methods of security enforcement. :-) - Ted From owner-ipsec Tue Jan 27 09:29:24 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA17734 for ipsec-outgoing; Tue, 27 Jan 1998 09:21:29 -0500 (EST) Message-Id: <34CDED64.9FA9FF66@lucent.com> Date: Tue, 27 Jan 1998 08:21:24 -0600 From: "David W. Faucher" Organization: Lucent Technologies X-Mailer: Mozilla 4.03 [en] (WinNT; U) Mime-Version: 1.0 To: "Theodore Y. Ts'o" Original-Cc: Daniel Harkins , bkavsan@ire-ma.com, Charles Lynn , "C. Harald Koch" , ipsec@tis.com Subject: Re: some issues about IPSec References: <199801262230.RAA05131@dcl.MIT.EDU> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk A different approach would be to transmit an Informational message that would disrupt a current exchange. This would only require the ability to monitor for an ISAKMP/Oakley exchange and insert the Informational message (created from the monitored data) at the appopriate time. In other words, no need to reveal your IP address. Theodore Y. Ts'o wrote: > Date: Mon, 26 Jan 1998 12:41:57 -0800 > From: Daniel Harkins > > Since the responder won't begin exponentiation until receipt of the 2nd > message (which contains his cookie which he passed in the 1st) he at least > knows there's a peer at a particular IP address which "speaks" ISAKMP. > Therefore the SGW won't do the actual exponentiation if barraged with > hundreds of ISAKMP packets with spoofed source addresses. The attacker > has to receive the 1st response from the SGW and reply properly to get > the SGW to exponentiate. It might be easy to track down such an attacker > in this situation. > > Just to amplify a particular point which Dan made here. The key here is > that it's much harder to do a denial of service attack without revealing > your IP address, which presumably would make it much easier to trace > things back to you. At this point, one can use out-of-band methods of > security enforcement. :-) > > - Ted -- David W. Faucher Lucent Technologies - Bell Labs dfaucher@lucent.com (515) 747-8617 From owner-ipsec Tue Jan 27 13:41:53 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA19880 for ipsec-outgoing; Tue, 27 Jan 1998 13:38:34 -0500 (EST) Message-ID: <34CE2A48.57C9C65D@BayNetworks.com> Date: Tue, 27 Jan 1998 13:41:12 -0500 From: Shawn Mamros X-Mailer: Mozilla 4.0 [en] (WinNT; U) MIME-Version: 1.0 To: ipsec@tis.com Subject: ISAKMP alignment question X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Section 3 of the isakmp-08 draft (just before section 3.1) states: "[...] all ISAKMP messages MUST be aligned at 4-octet multiples." This was a wording change from the previous draft (-07), which stated that "all ISAKMP payloads MUST be aligned at 4-octet multiples." Does the change from "payloads" to "messages" mean that individual payloads within a message no longer have any requirements for byte alignment? I'll try to illustrate by example... IP compression can now be negotiated within the IPSEC DOI. IP compression specifies a two-octet compression parameter index (CPI). I assume that, in an ISAKMP Proposal payload which specifies IP compression, the SPI in the Proposal would actually be the CPI, and the SPI Size field will specify two octets as the length of the SPI. Would the first Transform payload for the proposal follow immediately after the two octet SPI/CPI (i.e., no byte alignment requirement for the Transform payload), or would the Transform payload need to be aligned on the nearest four-octet boundary (requiring two octets in between the end of the SPI/CPI and the start of the Transform)? The Payload Length of the Proposal offers no help here, since that length must include the length(s) of any Transform(s) associated with the proposal. Any and all answers will be appreciated. Thanks... -Shawn Mamros E-mail to: smamros@BayNetworks.com (also smamros@newoak.com) From owner-ipsec Tue Jan 27 18:00:32 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA21737 for ipsec-outgoing; Tue, 27 Jan 1998 17:57:48 -0500 (EST) Message-Id: <3.0.32.19980127180907.00adc2a4@bl-mail1.corpeast.baynetworks.com> X-Sender: ndoraswa_pop@bl-mail1.corpeast.baynetworks.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Tue, 27 Jan 1998 18:09:08 -0500 To: Shawn Mamros , ipsec@tis.com From: Naganand Doraswamy Subject: Re: ISAKMP alignment question Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Shawn, As the document clearly says messages, I would assume that individual payloads do not need aligment and I would assume that the transform payload would immediatly start after the CPI. --Naganand ----------------------------------------------------------------- Naganand Doraswamy (978)916-1323 (O) Bay Architecture Lab (978)670-8153 (Fax) 3 Federal St, Mail Stop BL3-03 Billerica, MA 01821 From owner-ipsec Wed Jan 28 11:24:35 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA28387 for ipsec-outgoing; Wed, 28 Jan 1998 11:15:57 -0500 (EST) Message-Id: <3.0.5.32.19980128104538.009af390@homebase.htt-consult.com> X-Sender: rgm-sec@homebase.htt-consult.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 28 Jan 1998 10:45:38 +0000 To: ipsec@tis.com From: Robert Moskowitz Subject: Tunnel Vs Transport Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Sorry I have been offline, so to speak as I get situated in my new job (that will be tightly tied into this workgroup for a while :). I will attempt to typify my view of Tunnel vs Transport and why I feel that Transport is better, but Tunnel what we will be doing for some time.... I am writing this at a conference during a presentation that I only care a little about, compared to getting this note off. So it might be a little garbled... In transport, we slide IPsec between the IP and transport headers. This works just great on a host to host in a NON-NAT environment. IE Intranets and Global Internet users. It cannot reliably be used in a NAT environment and in many roadwarrior senarios. It cannot be used in NAT as the SA is tied into the destination IP address, so for a road warrior, you will have to be prepared to let external addresses run wild within your network and support default routing to your IPsec box regardless if you do the IPsec on your NAT box or the end system. The same applies to a non mobile Internet user not behind a IPsec gateway. Thus transport is severly limited due to NAT. Oh, and AH is worst than ESP in this manner as the IP address in the header are immutable, so the IPsec must be done after the NAT. Some NATs are more functional than others that might make this workable, but this is very complex for the average implementor. In tunnel mode the IP packet is packed into another IP packet along with the IPsec header. Fine and dandy. In a host to host environment, there is a question as to what addresses to use for the inner and outer IP headers. If they are the same, that leaves a lot of known text to attack the packets. Bad news. So for the host to host, as indicated above, Transport is better. For the roadwarrior to gateway, Tunnel works well and in fact this is the MUST implement mode per the IDs. It is advisable that the above mentioned known text issue be addressed. Timestep has a draft out for the gateway to assign the inner source address. Besides this addressing the Known text, it can also help for those applications that are registered by IP address (so unuseable by ISP addresses of the roadwarrior). A 'standard' way of doing this assignment (INTEL is proposing using DHCP) is an IPsecond item. The inner destination address may not be an issue, as it is the address of the destination server, whereas the outer destination is the address is address of the gateway. For gateway to gateway tunnel is the only mode that can work consistantly. To use transport in this situation requires both networks to be globally addressed. Since it might be hard for an administrator to know which network they work with is or is not globally addressed, this can end up being intensive, administratively. This is added to the obvious packet reassembly issue of transport that was noted earlier. >From all of this, tunnel is used whenever the IPsec ends at a gateway. this is for network to network and remote system (roadwarrior or other) to network. Transport is used for end-to-end which is Intranet or exposed global systems. Transport might also be used in gateway management; tunnel could be used, but that might yield known text challenges (but since most gateways have at least 2 addresses, games can be played for the destination). i plan on starting with only tunnel mode deployment recommendation for the ANX (i am no longer involved in the deployment :). But transport mode will come up, Intranet-wise and gateway support. Transport mode will also come up when we can nest modes with transport end to end with tunnel between gateways. got to pay attention to the presentation again ;) Robert Moskowitz ICSA Security Interest EMail: rgm-sec@htt-consult.com From owner-ipsec Fri Jan 30 07:37:12 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA16062 for ipsec-outgoing; Fri, 30 Jan 1998 07:29:24 -0500 (EST) From: sariff@xiox.com Date: Thu, 29 Jan 98 23:16:07 Message-Id: <9800298861.AA886144567@xioxwest.xiox.com> To: ipsec@tis.com Subject: ISAKMP Content-Type: text Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi, The draft on ISAKMP does not detail, the protocol . Like the message header/format etc. where can I get this info, From owner-ipsec Fri Jan 30 11:03:54 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA17731 for ipsec-outgoing; Fri, 30 Jan 1998 10:58:40 -0500 (EST) Message-ID: <34D1FB53.9DBD468C@nt.com> Date: Fri, 30 Jan 1998 11:09:55 -0500 From: "Marcus Leech" Organization: Nortel Technology, Messaging and Security Infrastructure X-Mailer: Mozilla 4.03 [en] (X11; I; HP-UX A.09.05 9000/712) MIME-Version: 1.0 To: ipsec@tis.com Subject: IPSEC and NFS Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Has anyone on this list given any thought to how IPSEC and NFS can play nicely together? While host-to-host IPSEC can protect NFS transactions from outsiders, there's still the problem of the client (or heck, the server) cheating on things like uid,gid, etc. The question could, I suppose, be re-asked as how to make existing RPC systems (NFS being a prime example) use IPSEC in ways that make good security sense. [Sorry for injecting an admittedly tangential question to IPSEC itself, but the participants in this list are the most likely candidates for having thought about some of these issues...] -- ---------------------------------------------------------------------- Marcus Leech Mail: Dept 8M86, MS 012, FITZ Systems Security Architect Phone: (ESN) 393-9145 +1 613 763 9145 Messaging and Security Infrastructure Fax: (ESN) 395-1407 +1 613 765 1407 Nortel Technology mleech@nortel.ca -----------------Expressed opinions are my own, not my employer's------ From owner-ipsec Fri Jan 30 11:28:00 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA17989 for ipsec-outgoing; Fri, 30 Jan 1998 11:25:36 -0500 (EST) Message-Id: <3.0.1.32.19980130094944.006990e0@192.9.200.10> X-Sender: padma@192.9.200.10 X-Mailer: Windows Eudora Light Version 3.0.1 (32) Date: Fri, 30 Jan 1998 09:49:44 +0500 To: ipsec@tis.com From: Padma Goli Subject: question in AH Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by portal.ex.tis.com id LAA17986 Sender: owner-ipsec@ex.tis.com Precedence: bulk Hello IPsec folks! I have a question in AH. In AH header there is a variable length authentication data field that contains the Integrity Check Value (ICV) for the packet. This field may include explicit padding to ensure that the length of the AH header is an integral multiple of 32 bits (IPv4) or 64 bits (IPv6). My question is · What value should be inserted into the explicit padding bytes. Whether a single value is inserted into all of the bytes or a monotonically increasing value is to be stored? Thanks in advance . Padma. Padma Goli Rendzevous Onchip Pvt Ltd. First Floor, Plot No 14 New Vasavi Nagar, Karkhana Secunderbad -500019. Phone No : (040)7742606 email address : padma@trinc.com From owner-ipsec Fri Jan 30 12:55:08 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA18698 for ipsec-outgoing; Fri, 30 Jan 1998 12:52:48 -0500 (EST) Date: Fri, 30 Jan 1998 09:47:37 -0800 (PST) From: "Michael R. Eisler" Reply-To: "Michael R. Eisler" Subject: Re: IPSEC and NFS To: Marcus Leech Cc: ipsec@tis.com In-Reply-To: "Your message with ID" <34D1FB53.9DBD468C@nt.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk "Marcus Leech" wrote > Has anyone on this list given any thought to how IPSEC and NFS can play > nicely > together? While host-to-host IPSEC can protect NFS transactions from > outsiders, > there's still the problem of the client (or heck, the server) cheating > on things > like uid,gid, etc. > > The question could, I suppose, be re-asked as how to make existing RPC > systems > (NFS being a prime example) use IPSEC in ways that make good security > sense. Yes that is the question. Consumers of RPC like NFS tend to multiplex multiple user "sessions" on the same TCP connection. My understanding is that it would be difficult to impossible for IPSEC to switch security associations at that fine a granularity. The direction for NFS security is RFC 2203, which a new RPC security flavor, based on GSS-API. -mre From owner-ipsec Fri Jan 30 15:57:59 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA19989 for ipsec-outgoing; Fri, 30 Jan 1998 15:54:01 -0500 (EST) Message-Id: <199801302105.QAA16381@jekyll.piermont.com> To: "Michael R. Eisler" cc: Marcus Leech , ipsec@tis.com Subject: Re: IPSEC and NFS In-reply-to: Your message of "Fri, 30 Jan 1998 09:47:37 PST." Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Fri, 30 Jan 1998 16:05:02 -0500 From: "Perry E. Metzger" Sender: owner-ipsec@ex.tis.com Precedence: bulk "Michael R. Eisler" writes: > My understanding is that it would be difficult to impossible for > IPSEC to switch security associations at that fine a granularity. IPSEC is capable of managing a large number of security associations, but I suspect no one has anticipated doing so within a single TCP session. Perry From owner-ipsec Fri Jan 30 18:14:37 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA20899 for ipsec-outgoing; Fri, 30 Jan 1998 18:12:02 -0500 (EST) Message-Id: <3.0.3.32.19980130182036.0381d704@pop.pn.com> X-PGP-Key: X-Sender: rodney@pop.pn.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Fri, 30 Jan 1998 18:20:36 -0500 To: ipsec@tis.com From: Rodney Thayer Subject: IPSEC and NFS Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Let's see here. First of all we have authentication so a different host shouldn't be able to spoof uid/etc. Second, we intrinsically assume the host has some sort of internal security, so IPSec views it as "out of scope" if a known valid host misrepresents UID. I assume properly representing UID is a policy plumbing problem left to the NFS developer. Or, you could run TLS, I suppose. >Date: Fri, 30 Jan 1998 11:09:55 -0500 >From: "Marcus Leech" >Organization: Nortel Technology, Messaging and Security Infrastructure >X-Mailer: Mozilla 4.03 [en] (X11; I; HP-UX A.09.05 9000/712) >To: ipsec@tis.com >Subject: IPSEC and NFS >Sender: owner-ipsec@ex.tis.com > >Has anyone on this list given any thought to how IPSEC and NFS can play >nicely > together? While host-to-host IPSEC can protect NFS transactions from >outsiders, > there's still the problem of the client (or heck, the server) cheating >on things > like uid,gid, etc. > >The question could, I suppose, be re-asked as how to make existing RPC >systems > (NFS being a prime example) use IPSEC in ways that make good security >sense. > >[Sorry for injecting an admittedly tangential question to IPSEC itself, >but the > participants in this list are the most likely candidates for having >thought > about some of these issues...] > > >-- >---------------------------------------------------------------------- >Marcus Leech Mail: Dept 8M86, MS 012, FITZ >Systems Security Architect Phone: (ESN) 393-9145 +1 613 >763 9145 >Messaging and Security Infrastructure Fax: (ESN) 395-1407 +1 613 >765 1407 >Nortel Technology mleech@nortel.ca >-----------------Expressed opinions are my own, not my employer's------ > > -- Rodney Thayer From owner-ipsec Fri Jan 30 19:44:41 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA21406 for ipsec-outgoing; Fri, 30 Jan 1998 19:41:57 -0500 (EST) Message-ID: <34D21817.11730FC9@nortel.ca> Date: Fri, 30 Jan 1998 19:12:39 +0100 From: "Marcus Leech" Organization: Security Development X-Mailer: Mozilla 2.02 (X11; I; Linux 1.2.13 i486) MIME-Version: 1.0 To: "Angelos D. Keromytis" CC: ipsec@tis.com Subject: Re: IPSEC and NFS References: <199801302309.SAA00391@adk.gr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Angelos D. Keromytis wrote: > > I've been using NFS over IPsec to protect against outsider attacks for > a while now, but I don't see how NFS can be made insider-resistant > without major restructuring of the protocol. There's the implicit > assumption that the client kernel is behaving. Of course, you didn't > quite explain what your threat model was (hostile users on the client > machine I presume -- in which case IPsec+priviledged ports required > for the client can do wonders). > Cheers, Fair enough, I wasn't very clear on the threat model. I'm particularly concerned about things like PCs participating in NFS services, in which it's sooooo easy for the client to "cheat" in the sense of claiming a uid/gid that it has no "right" to. I'm afraid that your analysis of NFS requiring major restructuring to protect agaist this is correct. Secure RPC doesn't appear to be a reasonable fix for this either. Sigh. If I restrict an NFS server to only allowing SAs with hosts it knows "play by the rules"--in that user processes cannot fake legitimate NFS protocol (because they can't get a privileged port), then host-to-host IPSEC works. What a marvellous world it would be if I could always make that assumption... From owner-ipsec Fri Jan 30 22:20:32 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id WAA22315 for ipsec-outgoing; Fri, 30 Jan 1998 22:18:04 -0500 (EST) From: Dan McDonald Message-Id: <199801310330.TAA08285@kebe.eng.sun.com> Subject: Re: IPSEC and NFS To: Marcus.Leech.mleech@nt.com (Marcus Leech) Date: Fri, 30 Jan 1998 19:30:19 -0800 (PST) Cc: ipsec@tis.com In-Reply-To: <34D21817.11730FC9@nortel.ca> from "Marcus Leech" at Jan 30, 98 07:12:39 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk > I'm particularly concerned about things like PCs participating in > NFS services, in which it's sooooo easy for the client to "cheat" > in the sense of claiming a uid/gid that it has no "right" to. > I'm afraid that your analysis of NFS requiring major restructuring > to protect agaist this is correct. Secure RPC doesn't appear to > be a reasonable fix for this either. Sigh. This is why Mike & friends are using the GSSAPI and friends to solve this problem. On the other hand... > If I restrict an NFS server to only allowing SAs with hosts it knows "play > by the rules"--in that user processes cannot fake legitimate NFS protocol > (because they can't get a privileged port), then host-to-host IPSEC works. > What a marvellous world it would be if I could always make that > assumption... Yes, IPsec would help here immensely. The thing to remember is what granularity do you want? IPsec does session-by-session granularity (e.g. TCP connection, or UDP session). NFS requires even finer granularity than per-session. Dan From owner-ipsec Sat Jan 31 17:06:45 1998 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA27452 for ipsec-outgoing; Sat, 31 Jan 1998 16:56:04 -0500 (EST) Date: Sat, 31 Jan 1998 17:06:59 -0500 (EST) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <3.0.1.32.19980130094944.006990e0@192.9.200.10> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Padma Goli From: Stephen Kent Subject: Re: question in AH Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Padma, As stated in the AH document, the padding values are arbitrary. Thus there is not requirement for self-describing padding, nor a complimentary requirement to check for the same. The pad length is implied by the algorithm used, part of SA establishment. Steve