Re: proposed IPSEC changes/extensions
John Gilmore <gnu@toad.com> Tue, 05 November 1996 04:15 UTC
To: Stephen Kent <kent@bbn.com>
MMDF-Warning: Unable to confirm address in preceding line at neptune.TIS.COM
Cc: Karl Fox <karl@ascend.com>, Steven Bellovin <smb@research.att.com>, Hilarie Orman <ho@earth.hpc.org>, ipsec@TIS.COM
Subject: Re: proposed IPSEC changes/extensions
In-Reply-To: <v02130511aea3bd9313c1@[128.89.0.110]>
Date: Mon, 04 Nov 1996 20:15:07 -0800
From: John Gilmore <gnu@toad.com>
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
Message-ID: <9611050729.aa05541@neptune.TIS.COM>
> Let's just work on > designing the protocols to work correctly and assume that the crypto will > be secure under assumptions of known (and chosen) plaintext attacks. This > is a sufficiently hard task. Perhaps I'm just reacting to Stephen's wording, but I think that rather than "assuming" the crypto is secure against known and chosen plaintext attacks, we should use crypto algorithms that we "strongly believe" are secure. I advocate against the use of 1DES because it is often "assumed" to be secure -- but we know it isn't, and are within months of seeing demonstration proofs of its insecurity. John Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: ipsec@TIS.COM From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-esp-3des-md5-00.txt Date: Tue, 05 Nov 1996 09:42:11 -0500 Message-ID: <9611050942.aa17948@ietf.org> Sender: ipsec-approval@neptune.tis.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : Combined 3DES-CBC, HMAC and Replay Prevention Security Transform Author(s) : N. Doraswamy Filename : draft-ietf-ipsec-esp-3des-md5-00.txt Pages : 13 Date : 11/04/1996 This draft describes a combination of privacy, authentication, integrity and replay prevention into a single packet format. This document is the result of significant work by several major contributors and the IPsec working group as a whole. These contributors, cited later in this document, provided many of the key technical details summarized in this document. [IB93] [IBK93] Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-esp-3des-md5-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-esp-3des-md5-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-esp-3des-md5-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961104110923.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-esp-3des-md5-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-esp-3des-md5-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961104110923.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Tue Nov 5 19:14:25 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA02415 for ipsec-outgoing; Tue, 5 Nov 1996 18:54:37 -0500 (EST) X-Sender: kent@po1.bbn.com Message-Id: <v02130514aea58337258c@[128.89.0.110]> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 5 Nov 1996 18:57:41 -0500 To: John Gilmore <gnu@toad.com> From: kent@bbn.com (Stephen Kent) Subject: Re: proposed IPSEC changes/extensions Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: list John, You read more into my choice of words than I intended. My point was simply that we should focus on engineering the protocols with the intent that they will be used with crypto that is believed to be sufficiently strong as to not motivate lots of work on minimizing predictble plaintext. My rule of thumb in this work has long been that the subscriber data will often contain sufficiently amounts of predictable plaintext as to make it unnecessary to worry about the header predictability. I agree that predictable header data might make the search a bit easier for a given search engine design, but in the grand scheme of things it's not that big a deal. Steve From owner-ipsec Wed Nov 6 08:06:14 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA03792 for ipsec-outgoing; Wed, 6 Nov 1996 08:01:11 -0500 (EST) Date: Wed, 6 Nov 1996 08:02:53 -0500 (EST) From: John Kelley <johnk@tis.com> Message-Id: <199611061302.IAA18499@clipper.hq.tis.com> To: ipsec@ex.tis.com Subject: ANNOUNCEMENT -- New majordomo server Sender: owner-ipsec@ex.tis.com Precedence: list ANNOUNCEMENT All majordomo lists, including this one, that have been maintained on neptune.hq.tis.com, have been moved to portal.ex.tis.com. This has allowed us to upgrade our software and hardware to hopefully provide much better mailing list service. There may be a few rough spots during the transition and until all the pieces are fitted together. One major temporary problem is that the access to the current list archives is not available at this time. Another announcement will not be made when they are available, but the info file for each particular list will mention that they are back. Please send any problems you may see about the new server to majordomo-owner@ex.tis.com. Commands to the majordomo@neptune address will be forwarded to the new server for the forseeable future. For the most efficient response to commands or postings, it is recommended using the majordomo@ex.tis.com or <list>@ex.tis.com addresses. Thank you for your patience in this matter. -TIS Majordomo Administrators From owner-ipsec Wed Nov 6 16:04:30 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA05330 for ipsec-outgoing; Wed, 6 Nov 1996 16:00:43 -0500 (EST) Message-ID: <c=CA%a=_%p=NorTel_Secure_Ne%l=GRANNY-961105203416Z-5@bwdldb.ott.bnr.ca> From: Greg Carter <carterg@entrust.com> To: "'ipsec@tis.com'" <ipsec@tis.com> Cc: "'isakmp-oakley@cisco.com'" <isakmp-oakley@cisco.com> Subject: December IETF... Date: Tue, 5 Nov 1996 15:34:16 -0500 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.24 Sender: owner-ipsec@ex.tis.com Precedence: list Hello All, Can we expect revised drafts for any of ISAKMP OAKLEY ISAKMP-OAKLEY before the December IETF meetings? Thanks. -- ---- Greg Carter Nortel Secure Networks - Entrust carterg@entrust.com From owner-ipsec Wed Nov 6 16:06:24 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA05380 for ipsec-outgoing; Wed, 6 Nov 1996 16:05:05 -0500 (EST) Message-Id: <199611060221.SAA19853@toad.com> X-Authentication-Warning: toad.com: Host localhost [127.0.0.1] didn't use HELO protocol To: kent@bbn.com (Stephen Kent) cc: John Gilmore <gnu@toad.com>, ipsec@tis.com, gnu@toad.com Subject: Re: proposed IPSEC changes/extensions In-reply-to: <v02130514aea58337258c@[128.89.0.110]> Date: Tue, 05 Nov 1996 18:21:20 -0800 From: John Gilmore <gnu@toad.com> Sender: owner-ipsec@ex.tis.com Precedence: list > You read more into my choice of words than I intended. My point > was simply that we should focus on engineering the protocols with the > intent that they will be used with crypto that is believed to be > sufficiently strong as to not motivate lots of work on minimizing > predictble plaintext. Yep, we agree. Thanks for the clarification. John From owner-ipsec Wed Nov 6 16:43:17 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA05547 for ipsec-outgoing; Wed, 6 Nov 1996 16:41:47 -0500 (EST) Message-Id: <2.2.32.19961106165645.009ef380@pop.hq.tis.com> X-Sender: johnk@pop.hq.tis.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 06 Nov 1996 11:56:45 -0500 To: ipsec@tis.com From: poised-approval@tis.com (by way of "John C. Kelley" <johnk@tis.com>) Subject: BOUNCE poised@neptune.tis.com: Non-member submission from ["Donald E. Eastlake 3rd" <dee@cybercash.com>] Sender: owner-ipsec@ex.tis.com Precedence: list Approved New.poised Date: Tue, 5 Nov 1996 12:59:36 -0500 (EST) From: "Donald E. Eastlake 3rd" <dee@cybercash.com> To: "John W. Stewart III" <jstewart@mci.net> Cc: poised@TIS.COM Subject: Re: The NomCom Selection In-Reply-To: <199611051657.LAA01847@postoffice.Reston.mci.net> Message-Id: <Pine.SUN.3.91.961105123400.8908H-100000@cybercash.com> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII How about replacing the current: (4) Members of the IETF community must have attended at least 2 of the last 3 IETF meetings in order to volunteer. (5) Internet Society Board of Trustees, sitting members of the IAB, and sitting members of the IESG may not volunteer. (6) The Chair randomly selects the 10 voting volunteers from the pool of names of volunteers. with: (4) Members of the IETF community must have attended at least 2 of the last 3 IETF meetings in order to volunteer. The list of volunteers shall be made public before the selection of voting volunteers. (5) Internet Society Board of Trustees, sitting members of the IAB, and sitting members of the IESG may not volunteer. (6) The Chair randomly selects the 10 voting volunteers from the pool of names of volunteers by a method publicly verifiable as unbiased and fair. For example, selecting from the pool using an exact preannounced algorithm based on future public random numbers such as public lottery winning nubmers. This leaves 5 unchanged, adds publishing the volunteer list to 4, so people can see if they have been left out and see if some they do not think eligible have been included, and adds one sentence plus a few additional words to item 6. I think this proposed wording demonstrates that the pages of specific procedures some were arguing against isn't necessary and wasn't what I had in mind anyway. If someone wants, I'd by happy to write some code into which you enter the volunteer list length and a string of digits and it spews out the list of selectees. This could be issued as informational RFC in source code so anyone could compile and run it. Donald PS: Some other comments I had after looking at the exact wording in the current RFC: I'm a bit surprised the attendance criteria have been tightened up so much. 2 out of the last 3 meetings is pretty stringent. As I recall, it was originally much more lax (like 2 meetings ever). And I think that if I was writing this, I'd exclude ISOC employees and members of the IETF secretariate, essentially anyone whose attendance at IETF was being paid for by part of the I* mechanism, from being on the nomcom. But these are minor points in my mind and I'm not suggesting changing them unless others feel it important. They don't compare with fixing the selection to be demonstrably fair. On Tue, 5 Nov 1996, John W. Stewart III wrote: > Date: Tue, 05 Nov 1996 11:57:56 -0500 > From: John W. Stewart III <jstewart@mci.net> > To: William Allen Simpson <wsimpson@greendragon.com> > Cc: poised@TIS.COM > Subject: Re: The NomCom Selection > > > the topic is whether something should be added to the > nomcomm procedures such that the selection of the > nomcomm from the pool of volunteers is independantly > verifiable. the last several messages have basically > been in favor of that in principle. there's a specific > proposal on the table from donald eastlake. are we > getting to consensus on adding something to the docs > about this? does someone want to propose specific text? > > /jws > ===================================================================== Donald E. Eastlake 3rd +1 508-287-4877(tel) dee@cybercash.com 318 Acton Street +1 508-371-7148(fax) dee@world.std.com Carlisle, MA 01741 USA +1 703-620-4200(main office, Reston, VA) http://www.cybercash.com http://www.eff.org/blueribbon.html From owner-ipsec Wed Nov 6 16:48:09 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA05614 for ipsec-outgoing; Wed, 6 Nov 1996 16:46:46 -0500 (EST) Message-ID: <c=CA%a=_%p=NorTel_Secure_Ne%l=GRANNY-961105203416Z-5@bwdldb.ott.bnr.ca> From: Greg Carter <carterg@entrust.com> To: "'ipsec@tis.com'" <ipsec@tis.com> Cc: "'isakmp-oakley@cisco.com'" <isakmp-oakley@cisco.com> Subject: December IETF... Date: Tue, 5 Nov 1996 15:34:16 -0500 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.24 Sender: owner-ipsec@ex.tis.com Precedence: list Hello All, Can we expect revised drafts for any of ISAKMP OAKLEY ISAKMP-OAKLEY before the December IETF meetings? Thanks. -- ---- Greg Carter Nortel Secure Networks - Entrust carterg@entrust.com From owner-ipsec Wed Nov 6 17:30:58 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA05874 for ipsec-outgoing; Wed, 6 Nov 1996 17:29:00 -0500 (EST) Message-Id: <199611062231.OAA24293@spook> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: Greg Carter <carterg@entrust.com> Cc: "'ipsec@tis.com'" <ipsec@tis.com>, "'isakmp-oakley@cisco.com'" <isakmp-oakley@cisco.com> Subject: Re: December IETF... In-Reply-To: Your message of "Tue, 05 Nov 1996 15:34:16 EST." <c=CA%a=_%p=NorTel_Secure_Ne%l=GRANNY-961105203416Z-5@bwdldb.ott.bnr.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 06 Nov 1996 14:31:13 -0800 From: Daniel Harkins <dharkins@cisco.com> Sender: owner-ipsec@ex.tis.com Precedence: list > Can we expect revised drafts for any of > ISAKMP > OAKLEY > ISAKMP-OAKLEY > > before the December IETF meetings? The short answer is yes; I believe so; and, yes. The ISAKMP base spec is being edited presently and once that's done I'm going to make one last cursory check of rev 2 of the ISAKMP-Oakley draft to make sure everything is coherent. I was shooting for this Friday and that may still happen. If not then 1st thing next week. I believe the Oakley draft is also being revised, but I'm not sure the timeframe. regards, Dan. ------------------------------------------------------------------------------- Dan Harkins | E-mail: dharkins@cisco.com Network Protocol Security, cisco Systems | phone: +1 (408) 526-5905 170 W. Tasman Drive | fax: +1 (408) 526-4952 San Jose, CA 95134-1706, U.S.A. | ICBM: 37.45N, 122.03W ------------------------------------------------------------------------------- For your safety and the safety of others: concealed carry, and strong crypto ------------------------------------------------------------------------------- From owner-ipsec Thu Nov 7 08:00:42 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA07741 for ipsec-outgoing; Thu, 7 Nov 1996 07:53:53 -0500 (EST) Message-Id: <199611070328.WAA00202@smb.research.att.com.research.att.com> X-Authentication-Warning: smb.research.att.com.research.att.com: smb owned process doing -bs From: Steve Bellovin <smb@research.att.com> To: ipsec@tis.com Subject: compression and encryption Date: Wed, 06 Nov 1996 20:54:39 -0500 Sender: owner-ipsec@ex.tis.com Precedence: list I've been thinking a lot about doing compression over a lossy medium such as IP. The problem is that the receiver can lose compression synchronization. While there may be other ways to handle this, one that has been suggested is the ``resync every n packets'' approach. That is, the sender would include a sequence number in each packet, so the receiver could detect missing packets; every so often, a flag bit would be set or the sequence number would be set to 0, and a new compression state would be initialized. This has the effect of tying together a sequence of packets -- if a packet in the sequence is lost, all subsequent packets until the next resync point are also lost, because they cannot be decompressed. This implies that compression over a lossy medium, using this resync algorithm, acts as a packet loss multiplier -- the loss of one packet will often cause the loss of other packets as well. Call the probability of loss of an individual packet 'p'. (We will assume that loss probability for separate packets is independent. Whether or not this is true may be dependent on the implementation strategies of various routers, and on the hardware error characteristics of the underlying media.) Every 'n' packets, the compression state is reset. We wish to calculate P, the fraction of packets lost out of a burst of n. The first packet is dropped with probability p, and hence arrives with probability 1-p. The second packet arrives successfully if and only (a) it isn't dropped, and (b) the packet preceeding it isn't dropped. In other words, the probability of safe arrival of the second packet in the burst is (1-p)^2. Similarly, we see that for packet 'i', 1<=i<=n, it arrives safely with probability (1-p)^i. We can calculate the average number of safely arriving packets in a burst by adding the average number of copies of each individual packet that arrive -- (i-p)^i -- and dividing by n. Subtracting that from 1 gives the loss probability: P = 1 - sum(i=1 to n) (1-p)^i / n (Btw, I've confirmed this equation via a simulation.) Here are the results of the equation for packet loss probabilities ranging from .01 to .12, and burst sizes ranging from 1 to 16: 0.01 0.02 0.03 0.04 0.05 0.06 0.07 0.08 0.09 0.10 0.11 0.12 ---------------------------------------------------------------------- 1 0.01 0.02 0.03 0.04 0.05 0.06 0.07 0.08 0.09 0.10 0.11 0.12 2 0.01 0.03 0.04 0.06 0.07 0.09 0.10 0.12 0.13 0.15 0.16 0.17 3 0.02 0.04 0.06 0.08 0.10 0.12 0.13 0.15 0.17 0.19 0.20 0.22 4 0.02 0.05 0.07 0.10 0.12 0.14 0.16 0.18 0.21 0.23 0.25 0.27 5 0.03 0.06 0.09 0.11 0.14 0.17 0.19 0.22 0.24 0.26 0.29 0.31 6 0.03 0.07 0.10 0.13 0.16 0.19 0.22 0.25 0.27 0.30 0.32 0.35 7 0.04 0.08 0.11 0.15 0.18 0.21 0.24 0.27 0.30 0.33 0.36 0.38 8 0.04 0.09 0.13 0.16 0.20 0.24 0.27 0.30 0.33 0.36 0.39 0.41 9 0.05 0.09 0.14 0.18 0.22 0.26 0.29 0.33 0.36 0.39 0.42 0.44 10 0.05 0.10 0.15 0.20 0.24 0.28 0.31 0.35 0.38 0.41 0.44 0.47 11 0.06 0.11 0.16 0.21 0.26 0.30 0.34 0.37 0.41 0.44 0.47 0.50 12 0.06 0.12 0.18 0.23 0.27 0.32 0.36 0.39 0.43 0.46 0.49 0.52 13 0.07 0.13 0.19 0.24 0.29 0.33 0.38 0.41 0.45 0.48 0.51 0.54 14 0.07 0.14 0.20 0.25 0.30 0.35 0.39 0.43 0.47 0.50 0.54 0.56 15 0.08 0.15 0.21 0.27 0.32 0.37 0.41 0.45 0.49 0.52 0.55 0.58 16 0.08 0.15 0.22 0.28 0.34 0.38 0.43 0.47 0.51 0.54 0.57 0.60 The first line is the loss probability; the first column is the burst size. We know empirically that a loss probability of .05 is not atypical within the U.S.; the transoceanic trunks can have loss probabilities of .15 or thereabouts. (The packet loss figure reported by 'ping' is a measure of the round trip packet loss, which is too pessimistic. If g is the loss figure reported by ping, the one-way loss can be approximated as 1-sqrt(1-g), since the packet and the response together have more or less independent loss probabilities.) We also know that when packet losses get above 10%, the TCP congestion control algorithms will serve to cut throughput drastically. (N.B. The 10% figure is based on my experience; I haven't analyzed it or even checked the literature...) Our goal, then, must be to keep P below .1, or the resulting TCP reactions will more than compensate for the gains from copmression. We can see from the chart that for p=.05, we must keep n<=4. That is, no more than every fourth packet, the compression state must be reset. For lossy links, the burst size should be 1. One more problem with larger burst sizes should be noted. Even independent of the congestion control algorithms, TCP does only a finite number of retransmissions. Depending on the stack, this number may be surprisingly low. If too many packets in a burst are lost -- or if the resync packet following a group of useless packets is lost -- it is possible that the connection will be aborted. Given all this, it isn't clear how to implement compression under IPSEC. Picking a standard now is clearly premature; we need to investigate various choices. For example, 'n' might be negotiated during the key management exchange. But it isn't clear how a host would know when to pick a large 'n' or when to pick a small 'n'. It might also be desirable to let systems adapt dynamically. For example, a receiver might note the loss rate on received packets, as determined by the sequence numbers, and send periodically send a control packet. The sender could adjust its 'n' accordingly. (Receivers don't need to know 'n'; the change can be made unilaterally by the sender.) Of course, the rate of such messages -- which are reminscent of the link quality messages in PPP -- might need to be negotiable too. But the prospect of any such messages, with the consequent implications for packet formats, is yet another reason to hold off on a compression standard. We should also analyze just how much compression will help. On a typical dial-up link -- the market for this technology -- I suspect that not much text is sent. GIF and JPEG files are already compressed, and are not further compressible. There is a potentially large gain from VJ-like header compression, which we also lose with IPSEC. It might be possible to use our cryptographic state to implement some form of this. If we use per-connection keying, much of the TCP and IP headers can be reconstructed by caching the connection ID information in the security association table, and rebuilding the headers at the far end. I'll leave it to someone else to do the detailed design, but my gut feeling is that this is a bigger win than, say, LZW data compression. A final choice, for some people, might be to let their ISP do the encryption at the POP. (Please, return to your seats. I'm well aware of the implications of this...) Suppose that someone made IPSEC-capable terminal servers, with secure cryptographic hardware. The user's travel key could be transmitted to this box via a cryptographically protected exchange. The traffic is thus protected from the POP to the user's host (or firewall). It might even be desirable to do AH end-to-end (sacrificing VJ header compression but retaining modem or PPP compression), resulting in a final packet format of IP-ESP-AH-data. (I don't remember if this was in Steve Kent's list.) For most users and most data, the threat model is such that POP-to-firewall secrecy is good enough, provided that the ISP can't impersonate them. (I would note that most people trust phone lines far more than they trust the Internet. While I suspect that the Internet isn't quite as dangerous -- nor phone lines quite as safe -- as is generally believed, I do think that on the whole, the perception is correct.) Based on all this, I make the following recommendations: a) we proceed with ESP as it is now. No changes should be made, or hooks left, for compression. b) the key management exchanges should permit the negotiation of an arbitrary set of compression parameters, for when something is defined. c) we investigate IPSEC header compression. d) the IPSEC architecture must allow for the header formats resulting from POP-based encryption. Comments? From owner-ipsec Thu Nov 7 12:16:13 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA09118 for ipsec-outgoing; Thu, 7 Nov 1996 12:13:34 -0500 (EST) Message-Id: <2.2.16.19961107171238.2607fa9c@pop3.pn.com> X-Sender: rodney@pop3.pn.com X-Mailer: Windows Eudora Pro Version 2.2 (16) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 07 Nov 1996 12:12:38 -0500 To: Steve Bellovin <smb@research.att.com> From: Rodney Thayer <rodney@sabletech.com> Subject: Re: compression and encryption Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: list When my customers have run compression I've seen them find acceptable benefit from using non-history-based compression, which is to say I feel it's fine to do a reset after every packet. This case side-steps your analysis. I don't have enough information at my fingertips to confirm your simulation matches the field data I have seen. If someone wants to accept the potential impact of using a history-based compression scheme I don't see any reason to architect the protocol to stop them. On the other hand, if there's not 'rough consensus' for putting compression into ESP then fine, don't put it in. There's still the 'next header' field so the stand-alone compression transform can be used. At 08:54 PM 11/6/96 -0500, you wrote: >I've been thinking a lot about doing compression over a lossy medium >such as IP. The problem is that the receiver can lose compression >synchronization. While there may be other ways to handle this, >one that has been suggested is the ``resync every n packets'' >approach. That is, the sender would include a sequence number in >each packet, so the receiver could detect missing packets; every >so often, a flag bit would be set or the sequence number would be >set to 0, and a new compression state would be initialized. This >has the effect of tying together a sequence of packets -- if a >packet in the sequence is lost, all subsequent packets until the >next resync point are also lost, because they cannot be decompressed. >This implies that compression over a lossy medium, using this resync >algorithm, acts as a packet loss multiplier -- the loss of one >packet will often cause the loss of other packets as well. > >Call the probability of loss of an individual packet 'p'. (We will assume >that loss probability for separate packets is independent. Whether or >not this is true may be dependent on the implementation strategies of >various routers, and on the hardware error characteristics of the >underlying media.) Every 'n' packets, the compression state is reset. >We wish to calculate P, the fraction of packets lost out of a burst of n. > >The first packet is dropped with probability p, and hence arrives with >probability 1-p. The second packet arrives successfully if and only >(a) it isn't dropped, and (b) the packet preceeding it isn't dropped. >In other words, the probability of safe arrival of the second packet in >the burst is (1-p)^2. Similarly, we see that for packet 'i', 1<=i<=n, >it arrives safely with probability (1-p)^i. We can calculate the average >number of safely arriving packets in a burst by adding the average number >of copies of each individual packet that arrive -- (i-p)^i -- and >dividing by n. Subtracting that from 1 gives the loss probability: > > P = 1 - sum(i=1 to n) (1-p)^i / n > >(Btw, I've confirmed this equation via a simulation.) > >Here are the results of the equation for packet loss probabilities >ranging from .01 to .12, and burst sizes ranging from 1 to 16: > > 0.01 0.02 0.03 0.04 0.05 0.06 0.07 0.08 0.09 0.10 0.11 0.12 > ---------------------------------------------------------------------- > 1 0.01 0.02 0.03 0.04 0.05 0.06 0.07 0.08 0.09 0.10 0.11 0.12 > 2 0.01 0.03 0.04 0.06 0.07 0.09 0.10 0.12 0.13 0.15 0.16 0.17 > 3 0.02 0.04 0.06 0.08 0.10 0.12 0.13 0.15 0.17 0.19 0.20 0.22 > 4 0.02 0.05 0.07 0.10 0.12 0.14 0.16 0.18 0.21 0.23 0.25 0.27 > 5 0.03 0.06 0.09 0.11 0.14 0.17 0.19 0.22 0.24 0.26 0.29 0.31 > 6 0.03 0.07 0.10 0.13 0.16 0.19 0.22 0.25 0.27 0.30 0.32 0.35 > 7 0.04 0.08 0.11 0.15 0.18 0.21 0.24 0.27 0.30 0.33 0.36 0.38 > 8 0.04 0.09 0.13 0.16 0.20 0.24 0.27 0.30 0.33 0.36 0.39 0.41 > 9 0.05 0.09 0.14 0.18 0.22 0.26 0.29 0.33 0.36 0.39 0.42 0.44 > 10 0.05 0.10 0.15 0.20 0.24 0.28 0.31 0.35 0.38 0.41 0.44 0.47 > 11 0.06 0.11 0.16 0.21 0.26 0.30 0.34 0.37 0.41 0.44 0.47 0.50 > 12 0.06 0.12 0.18 0.23 0.27 0.32 0.36 0.39 0.43 0.46 0.49 0.52 > 13 0.07 0.13 0.19 0.24 0.29 0.33 0.38 0.41 0.45 0.48 0.51 0.54 > 14 0.07 0.14 0.20 0.25 0.30 0.35 0.39 0.43 0.47 0.50 0.54 0.56 > 15 0.08 0.15 0.21 0.27 0.32 0.37 0.41 0.45 0.49 0.52 0.55 0.58 > 16 0.08 0.15 0.22 0.28 0.34 0.38 0.43 0.47 0.51 0.54 0.57 0.60 > >The first line is the loss probability; the first column is the >burst size. > >We know empirically that a loss probability of .05 is not atypical >within the U.S.; the transoceanic trunks can have loss probabilities >of .15 or thereabouts. (The packet loss figure reported by 'ping' is a >measure of the round trip packet loss, which is too pessimistic. >If g is the loss figure reported by ping, the one-way loss can be >approximated as 1-sqrt(1-g), since the packet and the response >together have more or less independent loss probabilities.) > >We also know that when packet losses get above 10%, the TCP congestion >control algorithms will serve to cut throughput drastically. (N.B. >The 10% figure is based on my experience; I haven't analyzed it or >even checked the literature...) Our goal, then, must be to keep >P below .1, or the resulting TCP reactions will more than compensate >for the gains from copmression. > >We can see from the chart that for p=.05, we must keep n<=4. That >is, no more than every fourth packet, the compression state must >be reset. For lossy links, the burst size should be 1. > >One more problem with larger burst sizes should be noted. Even >independent of the congestion control algorithms, TCP does only a >finite number of retransmissions. Depending on the stack, this >number may be surprisingly low. If too many packets in a burst >are lost -- or if the resync packet following a group of useless >packets is lost -- it is possible that the connection will be >aborted. > >Given all this, it isn't clear how to implement compression under >IPSEC. Picking a standard now is clearly premature; we need to >investigate various choices. For example, 'n' might be negotiated >during the key management exchange. But it isn't clear how a host >would know when to pick a large 'n' or when to pick a small 'n'. >It might also be desirable to let systems adapt dynamically. For >example, a receiver might note the loss rate on received packets, >as determined by the sequence numbers, and send periodically send >a control packet. The sender could adjust its 'n' accordingly. >(Receivers don't need to know 'n'; the change can be made unilaterally >by the sender.) Of course, the rate of such messages -- which are >reminscent of the link quality messages in PPP -- might need to be >negotiable too. But the prospect of any such messages, with the >consequent implications for packet formats, is yet another reason to >hold off on a compression standard. > >We should also analyze just how much compression will help. On a >typical dial-up link -- the market for this technology -- I suspect >that not much text is sent. GIF and JPEG files are already >compressed, and are not further compressible. > >There is a potentially large gain from VJ-like header compression, >which we also lose with IPSEC. It might be possible to use our >cryptographic state to implement some form of this. If we use >per-connection keying, much of the TCP and IP headers can be >reconstructed by caching the connection ID information in the >security association table, and rebuilding the headers at the far >end. I'll leave it to someone else to do the detailed design, but >my gut feeling is that this is a bigger win than, say, LZW data >compression. > >A final choice, for some people, might be to let their ISP do the >encryption at the POP. (Please, return to your seats. I'm well >aware of the implications of this...) Suppose that someone made >IPSEC-capable terminal servers, with secure cryptographic hardware. >The user's travel key could be transmitted to this box via a >cryptographically protected exchange. The traffic is thus protected >from the POP to the user's host (or firewall). It might even be >desirable to do AH end-to-end (sacrificing VJ header compression but >retaining modem or PPP compression), resulting in a final packet format >of IP-ESP-AH-data. (I don't remember if this was in Steve Kent's >list.) For most users and most data, the threat model is such that >POP-to-firewall secrecy is good enough, provided that the ISP can't >impersonate them. (I would note that most people trust phone lines >far more than they trust the Internet. While I suspect that the >Internet isn't quite as dangerous -- nor phone lines quite as safe -- >as is generally believed, I do think that on the whole, the perception >is correct.) > >Based on all this, I make the following recommendations: > > a) we proceed with ESP as it is now. No changes should > be made, or hooks left, for compression. > > b) the key management exchanges should permit the negotiation > of an arbitrary set of compression parameters, for when something > is defined. > > c) we investigate IPSEC header compression. > > d) the IPSEC architecture must allow for the header formats > resulting from POP-based encryption. > >Comments? > > > > Rodney Thayer <rodney@sabletech.com> +1 617 332 7292 Sable Technology Corp, 246 Walnut St., Newton MA 02160 USA Fax: +1 617 332 7970 http://www.shore.net/~sable Communications Software Development From owner-ipsec Thu Nov 7 14:29:28 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA10119 for ipsec-outgoing; Thu, 7 Nov 1996 14:28:35 -0500 (EST) Date: Thu, 7 Nov 1996 14:30:23 -0500 (EST) Message-Id: <199611071930.OAA11081@picu.morningstar.com> From: Leonard Samuelson <lcs@morningstar.com> To: Rodney Thayer <rodney@sabletech.com> Cc: Steve Bellovin <smb@research.att.com>, ipsec@tis.com Subject: Re: compression and encryption In-Reply-To: <2.2.16.19961107171238.2607fa9c@pop3.pn.com> References: <2.2.16.19961107171238.2607fa9c@pop3.pn.com> Reply-To: lcs@morningstar.com (Len Samuelson) Sender: owner-ipsec@ex.tis.com Precedence: list Rodney Thayer writes: > When my customers have run compression I've seen them find acceptable > benefit from using non-history-based compression, which is to say I > feel it's fine to do a reset after every packet. This case side-steps > your analysis. I don't have enough information at my fingertips to > confirm your simulation matches the field data I have seen. Considering that compression is most likely to benefit "bulk data transfer", such as ftp & web (with relatively large packet sizes); and considering that compression doesn't help much in non-bulk activities such as telnet (with small packet sizes), perhaps non-history-based compression might be a reasonable approach. However, perhaps much of the bulk data transfer that takes place is pre-compressed for archival storage anyway, and therefore is basically incompressible. Would this remain true for secured transmissions too? > Steve Bellovin writes: > >Based on all this, I make the following recommendations: > > > > a) we proceed with ESP as it is now. No changes should > > be made, or hooks left, for compression. > > > > b) the key management exchanges should permit the negotiation > > of an arbitrary set of compression parameters, for when something > > is defined. > > > > c) we investigate IPSEC header compression. > > > > d) the IPSEC architecture must allow for the header formats > > resulting from POP-based encryption. > > > >Comments? -- Leonard Samuelson, Ascend Communications, Inc. 614-326-6824 From owner-ipsec Thu Nov 7 15:01:04 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA10231 for ipsec-outgoing; Thu, 7 Nov 1996 15:00:33 -0500 (EST) Message-ID: <01BBCCBB.B8CB4320@bill.scli.com> From: Bill Hunt <bill@vpnet.com> To: "ipsec@tis.com" <ipsec@tis.com>, "'Steve Bellovin'" <smb@research.att.com> Subject: RE: compression and encryption Date: Thu, 7 Nov 1996 14:55:30 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: list good analysis. one minor note: If a burst is compressed, certainly uncompressing packet k requires receipt of packets 1..k-1. But if packet k is lost, is it necessary to retransmit packets 1..k-1? Or can the history be reset and the process begun again with k set as 1? The latter would allow a higher packet loss, since the "average" packet loss would be lower. ---------- From: Steve Bellovin[SMTP:smb@research.att.com] Sent: Wednesday, November 06, 1996 5:54 PM To: ipsec@tis.com Subject: compression and encryption I've been thinking a lot about doing compression over a lossy medium such as IP. [...] From owner-ipsec Thu Nov 7 15:20:51 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA10299 for ipsec-outgoing; Thu, 7 Nov 1996 15:20:38 -0500 (EST) Message-ID: <01BBCCBC.9C2048A0@bill.scli.com> From: Bill Hunt <bill@vpnet.com> To: Steve Bellovin <smb@research.att.com>, "'Rodney Thayer'" <rodney@sabletech.com> Cc: "ipsec@tis.com" <ipsec@tis.com> Subject: RE: compression and encryption Date: Thu, 7 Nov 1996 15:01:51 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: list We also run compression per packet. We find that the compression easily makes up for the encapsulation headers and other security overhead. In fact that is the specific reason we implemented it. However, we don't get anywhere near typical WAN compression rates. Enabling histories to include multiple packets would be very desirable. ---------- From: Rodney Thayer[SMTP:rodney@sabletech.com] Sent: Thursday, November 07, 1996 9:12 AM To: Steve Bellovin Cc: ipsec@tis.com Subject: Re: compression and encryption When my customers have run compression I've seen them find acceptable benefit from using non-history-based compression, which is to say I feel it's fine to do a reset after every packet. [...] From owner-ipsec Thu Nov 7 17:13:30 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA10670 for ipsec-outgoing; Thu, 7 Nov 1996 17:11:45 -0500 (EST) Message-ID: <c=US%a=_%p=TimeStep_Corpora%l=TSNTSRV2-961107221439Z-2162@tsntsrv2.timestep.com> X-MS-TNEF-Correlator: <c=US%a=_%p=TimeStep_Corpora%l=TSNTSRV2-961107221439Z-2162@tsntsrv2.timestep.com> From: Roy Pereira <rpereira@timestep.com> To: "'isakmp-oakley'" <isakmp-oakley@cisco.com>, "'IPSEC'" <ipsec@tis.com> Subject: S/WAN ISAKMP/Oakley testing... Date: Thu, 7 Nov 1996 17:14:39 -0500 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="---- =_NextPart_000_01BBCCCF.2A4FCCB0" Sender: owner-ipsec@ex.tis.com Precedence: list This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------ =_NextPart_000_01BBCCCF.2A4FCCB0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I'd like to talk about some of the 'magic' identifiers in ISAKMP. I'm talking about the values that aren't defined in v5 of the draft. - What transform ids are used for the ISAKMP proposal? - What ids are used for the ISAKMP proposal attributes "Group Identifier", Encryption Alg", "Hash Alg", and "Auth Alg" ? - What is the format of a SA proposal TLV ? Is the type and length 16 bits each ? Or are they 8 bits each ? - What is the ESP Proposal attribute "Cryptographic Synch" used for and when? - How do we transform a 8-byte ISAKMP SPI to a 4-byte ESP/AH SPI ? - The v5 ISAKMP draft states that the "Payload Length" in the SA payload is "in 4-octet units", but this is incorrect and should by in 1-octet units. - For the Certificate Payload, there aren't any identifiers for the Certificate Type and there is only one identifier for the Certificate Authority. - What ISAKMP exchange identifiers are used for the Oakley exchange modes? - What is the Notify message error "CONNECTED" used for? - What is the Notification Data? It's contents are not defined in the Internet DOI. Thanks. ------ =_NextPart_000_01BBCCCF.2A4FCCB0 Content-Type: application/ms-tnef Content-Transfer-Encoding: base64 eJ8+IisWAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQWAAwAOAAAAzAcLAAcAEQAOACcABAAvAQEggAMADgAAAMwHCwAH ABEADgAoAAQAMAEBCYABACEAAAAwQkMwQzdEN0VEMzdEMDExOTI2MTAwODA1RkZDNzIwMQALBwEN gAQAAgAAAAIAAgABBIABAB8AAABTL1dBTiBJU0FLTVAvT2FrbGV5IHRlc3RpbmcuLi4AiQkBA5AG ANAGAAAaAAAAAwAmAAAAAAADADYAAAAAAB4AcAABAAAAHwAAAFMvV0FOIElTQUtNUC9PYWtsZXkg dGVzdGluZy4uLgAAAgFxAAEAAAAlAAAAAbu3r1KJ/LaFVyKxEdCSXgCAX/xyAQQVWJwfATkvMNQA A6ywlQAAAAMALgAAAAAAAwAGEBAXr/gDAAcQawMAAB4ACBABAAAAZQAAAElETElLRVRPVEFMS0FC T1VUU09NRU9GVEhFTUFHSUNJREVOVElGSUVSU0lOSVNBS01QSU1UQUxLSU5HQUJPVVRUSEVWQUxV RVNUSEFUQVJFTlRERUZJTkVESU5WNU9GVEhFRFIAAAAAAwAQEAAAAAADABEQAQAAAAIBCRABAAAA mgMAAJYDAADiBgAATFpGdabceQ3/AAoBDwIVAqQD5AXrAoMAUBMDVAIAY2gKwHNldG4yBgAGwwKD MgPFAgBwhHJxEiJzdGVtAoPmMxMMD/9mNAPGBxMCg5Y1D38QhzYWv2Y3F+qIaGVsAyBEbGcCgC59 CoAIzwnZOxz/MjUeNQKACoENsQtgbmcxDDAzFJALA2xpMTTyNALRaS0g4wzQIOMLVVsWogwBYwBB E5BvFBBjIQVASSdkICDAa2WYIHRvJEAHQGsgAaCbCGAFQHMDcCQwb2YkQAkbgCAnAMBnaWMn/CBp DbACMAaQCJEEIAuAASOwU0FLTVAuIG0jsW0kcwuAZyTFJbJ27wdAClAEICWwYQVACsAJ8D4nBUAN sQuACYAnInY10SV2ZHJhAYAuCo8ib2cjcyw7IMAzNiIPLf8g6C0gVynSdCvgAIACEJ5yKBAmcAQg KhEgdRHwLyPgMqEloydkICNBcG/6cwdAPzF8Mv80DwdAJMCbAkAFEGIlAAeRIkcDYAx1cCOwJoci LCBF6m4FAHkFMGkCIBcgG+DBOjEiSGFzaDsFAHDZI+AiQSUAO7QgNT4poq8kMDKiKeElgWEGAEE3 2LhUTFY9ECOwPiR0OqArJDA8MmwJ8Gc8oTE20CBiaXQEIGUA0DuwHUBATwXANmIlsXkgOKdB+j0/ JbJFUzSQUDf/FTkQQzqSbwnAYXBodyYwEjE6cGg9ADanPDJ3pRuAbjU4SG8H4GQkYA53JDEyZz8g OC1iebdG4TRFRbBJJEI/IDRLlLFFoS9BSExTNThUKSL/K0A0RSvTJSABkDjiKcMlslAiUGF5HJBh I+BMf0FzPQAnMSWyP0JRFT4RIvsnMUzwbyOQEgA2kAMAQiD/OjE4wSWhPhFU8jpwBbAdAO8jkTwy O6AIYGwj4EugJyKuMVOqLCYx4EY3BUMEkP0msmNQEUXQURQ6QCWxNnG/KhUAcFaxJok29lj6VEDm 91pEPhECIGxDYAIgXiEmh99cD1lyPIIFsEIQeVfYMgP5NEVleBGxIABe6jZPJDB4T2FrQWBDYGLn BGJz+0RPJaNOI2AGkENgB4E1AB9jQQSQA2AFwEcQT05O4EVDVEVESFhmn2eoa1lSOtJEKeBhQEAj sHS+JwQgBaACMCaRZBRuI2AfKno3M22RBKBT4URPSf8sKC/rLi8szzCvCsFOsABw/mtXx3V8cL9x zws3GYJ3jwogHCEAexAAAEAAOQAgKZoR+cy7AQMA8T8JBAAAAgFHAAEAAAA6AAAAYz1VUzthPSA7 cD1UaW1lU3RlcCBDb3Jwb3JhO2w9VFNOVFNSVjItOTYxMTA3MjIxNDM5Wi0yMTYyAAAAAgH5PwEA AABaAAAAAAAAANynQMjAQhAatLkIACsv4YIBAAAAAAAAAC9PPVRJTUVTVEVQIENPUlBPUkFUSU9O L09VPVRJTUVTVEVQL0NOPVJFQ0lQSUVOVFMvQ049UlBFUkVJUkEAAAAeAPg/AQAAAAwAAABSb3kg UGVyZWlyYQACAfs/AQAAAFoAAAAAAAAA3KdAyMBCEBq0uQgAKy/hggEAAAAAAAAAL089VElNRVNU RVAgQ09SUE9SQVRJT04vT1U9VElNRVNURVAvQ049UkVDSVBJRU5UUy9DTj1SUEVSRUlSQQAAAB4A +j8BAAAADAAAAFJveSBQZXJlaXJhAEAABzDwoZgR+cy7AUAACDCgoSAS+cy7AQMADTT9PwAAAgEU NAEAAAAQAAAAVJShwCl/EBulhwgAKyolFx4APQABAAAAAQAAAAAAAAALACkAAAAAAAsAIwAAAAAA AgF/AAEAAABSAAAAPGM9VVMlYT1fJXA9VGltZVN0ZXBfQ29ycG9yYSVsPVRTTlRTUlYyLTk2MTEw NzIyMTQzOVotMjE2MkB0c250c3J2Mi50aW1lc3RlcC5jb20+AAAApOY= ------ =_NextPart_000_01BBCCCF.2A4FCCB0-- From owner-ipsec Thu Nov 7 21:17:37 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id VAA11227 for ipsec-outgoing; Thu, 7 Nov 1996 21:13:22 -0500 (EST) Message-Id: <199611080213.VAA20427@raptor.research.att.com> To: Rodney Thayer <rodney@sabletech.com> cc: ipsec@tis.com Subject: Re: compression and encryption Date: Thu, 07 Nov 1996 21:13:04 -0500 From: Steven Bellovin <smb@research.att.com> Sender: owner-ipsec@ex.tis.com Precedence: list When my customers have run compression I've seen them find acceptable benefit from using non-history-based compression, which is to say I feel it's fine to do a reset after every packet. This case side-steps your analysis. I don't have enough information at my fingertips to confirm your simulation matches the field data I have seen. It's quite compatible with n=1, which is more or less my point -- that we need to use very small burst sizes. 1 is a very nice low number, and it makes the protocol a lot simpler. If someone wants to accept the potential impact of using a history-based compression scheme I don't see any reason to architect the protocol to stop them. On the other hand, if there's not 'rough consensus' for putting compression into ESP then fine, don't put it in. There's still the 'next header' field so the stand-alone compression transform can be used. Yes. If we're going to do compression at this layer, that may be the right answer. But we should measure the effectiveness of compression when you have a dictionary in each packet, and the packets are ~512 bytes uncompressed. From owner-ipsec Thu Nov 7 21:20:54 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id VAA11248 for ipsec-outgoing; Thu, 7 Nov 1996 21:19:23 -0500 (EST) Message-Id: <199611080218.VAA21072@raptor.research.att.com> To: Bill Hunt <bill@vpnet.com> cc: "ipsec@tis.com" <ipsec@tis.com> Subject: Re: compression and encryption Date: Thu, 07 Nov 1996 21:18:07 -0500 From: Steven Bellovin <smb@research.att.com> Sender: owner-ipsec@ex.tis.com Precedence: list good analysis. one minor note: If a burst is compressed, certainly uncompressing packet k requires receipt of packets 1..k-1. But if packet k is lost, is it necessary to retransmit packets 1..k-1? Or can the history be reset and the process begun again with k set as 1? The latter would allow a higher packet loss, since the "average" packet loss would be lower. No, it isn't necessary to resend 1..k-1 -- those can be decompressed succesfully without packet k..n. You can't reset the history during the burst without a network-level ack/retransmit mechanism, which violates far too many layering assumptions in TCP/IP. My analysis was precisely for the simple case of ``I send what I want, you receive whatever you can''. From owner-ipsec Fri Nov 8 08:58:13 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA12382 for ipsec-outgoing; Fri, 8 Nov 1996 08:47:56 -0500 (EST) Date: Thu, 7 Nov 96 17:57:10 EST From: wdm@epoch.ncsc.mil (W. Douglas Maughan) Message-Id: <9611072257.AA10138@dolphin.ncsc.mil> To: isakmp-oakley@cisco.com, ipsec@tis.com, rpereira@timestep.com Subject: Re: S/WAN ISAKMP/Oakley testing... Sender: owner-ipsec@ex.tis.com Precedence: list Roy, > > I'd like to talk about some of the 'magic' identifiers in ISAKMP. I'm > talking about the values that aren't defined in v5 of the draft. > > > - What transform ids are used for the ISAKMP proposal? > - What ids are used for the ISAKMP proposal attributes "Group > Identifier", Encryption Alg", "Hash Alg", and "Auth Alg" ? > - What is the format of a SA proposal TLV ? Is the type and length 16 > bits each ? Or are they 8 bits each ? > - What is the ESP Proposal attribute "Cryptographic Synch" used for > and when? > - How do we transform a 8-byte ISAKMP SPI to a 4-byte ESP/AH SPI ? > - The v5 ISAKMP draft states that the "Payload Length" in the SA > payload is "in 4-octet units", but this is incorrect and should by in > 1-octet units. > - For the Certificate Payload, there aren't any identifiers for the > Certificate Type and there is only one identifier for the Certificate > Authority. > - What ISAKMP exchange identifiers are used for the Oakley exchange > modes? > - What is the Notify message error "CONNECTED" used for? > - What is the Notification Data? It's contents are not defined in the > Internet DOI. > As mentioned in an e-mail by Dan Harkins yesterday, there will be new drafts for ISAKMP, ISAKMP-Oakley Resolution, and the IP Security DOI early next week (i.e. Tues or Wed.). I think they will answer most, if not all, of the above "attribute" questions. Doug Maughan From owner-ipsec Fri Nov 8 10:46:43 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA12902 for ipsec-outgoing; Fri, 8 Nov 1996 10:43:26 -0500 (EST) Date: Fri, 8 Nov 1996 10:44:09 -0500 (EST) From: Ian Duncan <iduncan@Newbridge.com> X-Sender: iduncan@magnus2 Reply-To: Ian Duncan <iduncan@Newbridge.com> To: Steven Bellovin <smb@research.att.com> cc: ipsec@tis.com Subject: Re: compression and encryption In-Reply-To: <199611080213.VAA20427@raptor.research.att.com> Message-ID: <Pine.GSO.3.93.961108095127.8864W-100000@magnus2> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: list On Thu, 7 Nov 1996, Steven Bellovin wrote: > It's quite compatible with n=1, which is more or less my point -- that > we need to use very small burst sizes. 1 is a very nice low number, > and it makes the protocol a lot simpler. > > If someone wants to accept the potential impact of using a > history-based compression scheme I don't see any reason to > architect the protocol to stop them. On the other hand, if > there's not 'rough consensus' for putting compression into ESP > then fine, don't put it in. > > There's still the 'next header' field so the stand-alone > compression transform can be used. > > Yes. If we're going to do compression at this layer, that may be the > right answer. But we should measure the effectiveness of compression > when you have a dictionary in each packet, and the packets are ~512 > bytes uncompressed. A quick bit of hopefully helpful background -- A few years ago, when compression was being discussed in the context of PPP there was a proposal offered by HP for a 'stateless' compressor. I was a bit fuzzy on the details (and still am) but the essence was some clever folk had examined the nature of the available entropy in short bit streams and tuned some variant of LZ+ to focus at that level. The result claimed was better compression where "n=1". How much better and how much heat would get generated at both ends was never made clear. As well, there were some patent issues involved if memory serves. -- Ian Duncan <iduncan@Newbridge.com> Access Products Development Newbridge Networks Corp. From owner-ipsec Fri Nov 8 11:17:35 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA12999 for ipsec-outgoing; Fri, 8 Nov 1996 11:14:38 -0500 (EST) Date: Fri, 08 Nov 96 08:12:00 PST From: John H Wilson <John_H_Wilson@ccm.jf.intel.com> Message-ID: <Fri, 08 Nov 96 08:15:02 PST_1@ccm.jf.intel.com> To: owner-ipsec@portal.ex.tis.com, rodney@sabletech.com cc: ipsec@tis.com Subject: Re[2]: compression and encryption Sender: owner-ipsec@ex.tis.com Precedence: list Text item: I assume all these arguments apply equally well to the use of encryption algorithms that rely on "history". (Sorry, I've only recently been following the IPSEC mailing list) Are there any proposals to use stream ciphers in IPSEC? The n=1 case would be the equivalent of treating each packet as a separate stream. Right now, I'm interested in audio/video streams (already compressed; real-time operation). Re-transmit is not an option; but re-sync (of the encryption algorithm) would be vital. For n>1, would it be possible to transmit the stream offset in each packet to allow re-sync? ____________________________ Reply Separator _________________________________ >Subject: Re: compression and encryption >Author: owner-ipsec@portal.ex.tis.com at SMTPGATE >Date: 11/7/96 9:13 PM > > When my customers have run compression I've seen them find > acceptable benefit from using non-history-based compression, > which is to say I feel it's fine to do a reset after every > packet. This case side-steps your analysis. I don't have > enough information at my fingertips to confirm your simulation > matches the field data I have seen. > >It's quite compatible with n=1, which is more or less my point -- that >we need to use very small burst sizes. 1 is a very nice low number, >and it makes the protocol a lot simpler. > > If someone wants to accept the potential impact of using a > history-based compression scheme I don't see any reason to > architect the protocol to stop them. On the other hand, if > there's not 'rough consensus' for putting compression into ESP > then fine, don't put it in. > > There's still the 'next header' field so the stand-alone > compression transform can be used. > >Yes. If we're going to do compression at this layer, that may be the >right answer. But we should measure the effectiveness of compression >when you have a dictionary in each packet, and the packets are ~512 >bytes uncompressed. Text item: External Message Header The following mail header is for administrative use and may be ignored unless there are problems. ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. Precedence: list Sender: owner-ipsec@ex.tis.com From: Steven Bellovin <smb@research.att.com> Date: Thu, 07 Nov 1996 21:13:04 -0500 Subject: Re: compression and encryption cc: ipsec@tis.com To: Rodney Thayer <rodney@sabletech.com> Message-Id: <199611080213.VAA20427@raptor.research.att.com> Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id VAA112 27 for ipsec-outgoing; Thu, 7 Nov 1996 21:13:22 -0500 (EST) Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mailbag .jf.intel.com (8.8.2/8.7.3) with ESMTP id UAA29956 for <John_H_Wilson@ccm.jf.int el.com>; Thu, 7 Nov 1996 20:22:08 -0800 (PST) Received: from mailbag.jf.intel.com (root@mailbag.jf.intel.com [134.134.248.4]) by relay.jf.intel.com (8.8.2/8.7.3) with ESMTP id UAA08086 for <John_H_Wilson@cc m.jf.intel.com>; Thu, 7 Nov 1996 20:19:35 -0800 (PST) Return-Path: owner-ipsec@portal.ex.tis.com From owner-ipsec Fri Nov 8 13:13:52 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA13331 for ipsec-outgoing; Fri, 8 Nov 1996 13:10:17 -0500 (EST) Message-Id: <199611081808.NAA26663@raptor.research.att.com> To: John H Wilson <John_H_Wilson@ccm.jf.intel.com> cc: ipsec@tis.com Subject: Re: Re[2]: compression and encryption Date: Fri, 08 Nov 1996 13:08:09 -0500 From: Steven Bellovin <smb@research.att.com> Sender: owner-ipsec@ex.tis.com Precedence: list I assume all these arguments apply equally well to the use of encryption algorithms that rely on "history". Yup. (Sorry, I've only recently been following the IPSEC mailing list) Are there any proposals to use stream ciphers in IPSEC? There have been some such proposals. The n=1 case would be the equivalent of treating each packet as a separate stream. Right now, I'm interested in audio/video streams (already compressed; real-time operation). Re-transmit is not an option; but re-sync (of the encryption algorithm) would be vital. For n>1, would it be possible to transmit the stream offset in each packet to allow re-sync? All of the stream ciphers proposed include the current offset as part of each packet. From owner-ipsec Fri Nov 8 13:43:41 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA13403 for ipsec-outgoing; Fri, 8 Nov 1996 13:40:18 -0500 (EST) Date: Fri, 8 Nov 1996 13:40:14 -0500 Message-Id: <199611081840.NAA20494@relay.hq.tis.com> X-Sender: mike.sabin@postoffice.worldnet.att.net X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Steven Bellovin <smb@research.att.com> From: Michael Sabin <msabin@netcom.com> Subject: Re: compression and encryption Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: list At 02:13 AM 11/8/96 +0000, Steven Bellovin wrote: > When my customers have run compression I've seen them find > acceptable benefit from using non-history-based compression, > which is to say I feel it's fine to do a reset after every > packet. This case side-steps your analysis. I don't have > enough information at my fingertips to confirm your simulation > matches the field data I have seen. > >It's quite compatible with n=1, which is more or less my point -- that >we need to use very small burst sizes. 1 is a very nice low number, >and it makes the protocol a lot simpler. > > If someone wants to accept the potential impact of using a > history-based compression scheme I don't see any reason to > architect the protocol to stop them. On the other hand, if > there's not 'rough consensus' for putting compression into ESP > then fine, don't put it in. > > There's still the 'next header' field so the stand-alone > compression transform can be used. > >Yes. If we're going to do compression at this layer, that may be the >right answer. But we should measure the effectiveness of compression >when you have a dictionary in each packet, and the packets are ~512 >bytes uncompressed. > Below is a table of numbers that shows an example of the tradeoff between compression efficiency and the parameter n in a "reset after n packets" strategy. The table is from an appendix in <draft-sabin-esp-des3-lzs-md5-01.txt>. It is based on the LZS compression algorithm. Here's the row of the table that corresponds to 512-byte payloads: n: 1 2 4 8 16 32 Compression ratio: 1.58 1.73 1.89 2.01 2.08 2.11 In the case n=1, the compression boosts throughput by about 60%. (Headers are neglected here.) Larger values of n give better compression, obviously. ----------------------------------- >From <draft-sabin-esp-des3-lzs-md5-01.txt>: 9. Appendix: Guidelines for Resetting Compression Histories The following table offers some guidance on how frequently an LZS compression history can be reset. The table considers two parameters: "payload_bytes," the number of bytes in each payload; and "reset_bytes," the number of bytes between history resets. Reset_bytes is a multiple of payload_bytes, since an integer number of payloads is processed between resets. Each entry in the table shows the compression ratio that was achieved when compressing a test file with the corresponding values of payload_bytes and reset_bytes. The test file was the University of Calgary Text Compression Corpus [Calgary]. The length of the file prior to compression was 3,278,000 bytes. When the entire file was compressed as a single payload, a compression ratio of 2.34 resulted. | reset_bytes | 64 128 256 512 1024 2048 4096 8192 16384 ------------+----------------------------------------------------- packet_bytes| 64 | 1.18 1.26 1.37 1.48 1.61 1.74 1.84 1.89 1.92 128 | 1.28 1.40 1.53 1.67 1.82 1.93 1.99 2.03 256 | 1.43 1.56 1.71 1.86 1.98 2.05 2.08 512 | 1.58 1.73 1.89 2.01 2.08 2.11 1024 | 1.74 1.90 2.02 2.09 2.13 2048 | 1.91 2.03 2.10 2.14 4096 | 2.04 2.10 2.14 8192 | 2.11 2.14 16384 | 2.14 The table suggests that not there is not much degradation in compression ratio if the compression history is reset after several thousand bytes have been processed. Resetting after less than 1,000 bytes is probably too soon -- the compression ratio degrades significantly. But waiting longer than about 8,000 bytes gains little -- the compression ratio does not increase much. From owner-ipsec Fri Nov 8 17:14:58 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA13997 for ipsec-outgoing; Fri, 8 Nov 1996 17:09:31 -0500 (EST) Message-Id: <3.0.32.19961108141107.00929b90@earthlink.net> X-Sender: rmonsour@earthlink.net X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Fri, 08 Nov 1996 14:11:14 -0800 To: Steve Bellovin <smb@research.att.com> From: Bob Monsour <rmonsour@earthlink.net> Subject: Re: compression and encryption Cc: ipsec@tis.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: list Steve, that was a very thoughtful analysis. Thank you for spending the time and energy on it. Here are my thoughts on your recommendations. At 08:54 PM 11/6/96 -0500, Steve Bellovin wrote: > a) we proceed with ESP as it is now. No changes should > be made, or hooks left, for compression. Based on the data provided by Mike Sabin earlier today regarding the compression performance of stateless compression (repeated here): On 11/6, Mike Sabin wrote: >Here's the row of the table that corresponds to 512-byte payloads: > > n: 1 2 4 8 16 32 > Compression ratio: 1.58 1.73 1.89 2.01 2.08 2.11 > >In the case n=1, the compression boosts throughput by about 60%. >(Headers are neglected here.) Larger values of n give better >compression, obviously. I would suggest that we allow for statless compression to be implemented within the context of ESP. I would further suggest, as I did in an earlier posting (11/4) that this be done with some minor language changes to ESP: "...that the ESP draft simply state that compression is one of the negotiable security association attributes...In addition, the ESP draft would state that when the optional compression is implemented, it is performed prior to encryption. I would suggest that the appropriate language be added to the descriptions of the "sender" and "receiver" operations in the tunnel-mode and transport-mode descriptions (sections 4.1 and 4.2 of the June 6 draft)." This allows stateless compression functionality to be optionally deployed in the near term> It also allows the working group the necessary time and consideration needed to properly evaluate mechanisms for implementing statfull, multi-packet compression. I would suggest to you that this qualifies as "no changes or hooks", since the ESP transform is not modified in any way. > b) the key management exchanges should permit the negotiation > of an arbitrary set of compression parameters, for when something > is defined. Agree. > c) we investigate IPSEC header compression. In tunnel mode, the tunnelled headers are part of the payload that will be compressed. This will boost compression efficiency, since the headers are presumably very compressible. > d) the IPSEC architecture must allow for the header formats > resulting from POP-based encryption. > Agree. Thanks to all for listening. I look forward to comments from all (supporters and non-supporters alike). Bob Monsour rmonsour@earthlink.net From owner-ipsec Sun Nov 10 02:10:19 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id CAA15768 for ipsec-outgoing; Sun, 10 Nov 1996 02:01:41 -0500 (EST) Message-Id: <m0vKuqt-000MF6C@laptop> Date: Tue, 5 Nov 96 15:24 PST From: Phil Karn <karn@tis.com> To: smb@research.att.com CC: ipsec@tis.com Reply-To: karn@qualcomm.com In-reply-to: <199611070328.WAA00202@smb.research.att.com.research.att.com> (message from Steve Bellovin on Wed, 06 Nov 1996 20:54:39 -0500) Subject: Re: compression and encryption Sender: owner-ipsec@ex.tis.com Precedence: list I generally agree with Steve's analysis showing the intractability of doing compression at the IPSEC layer. Especially with the widespread use of application-level compression in the Internet, the lack of compression in IPSEC just doesn't strike me as a serious problem. I think VJ header compression is not nearly as important as once was, for several reasons: 1. Van originally designed his scheme when he had a 2400bps dialup modem and read his netnews over a telnet session. Today if you have 14.4kb/s, you're behind the curve. 2. Many of the things you used to do over a telnet/rlogin type session (where header overhead is most significant) are now done with intelligent local agents. Examples include email, netnews and web surfing. Most of these agents speak various client/server protocols over the wire with much larger average packet sizes as compared to character-at-a-time telnet. This makes header overhead much less significant. So while there's no reason to take out VJ header compression now that it exists, I no longer consider it essential. Phil From owner-ipsec Tue Nov 12 13:21:18 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA20434 for ipsec-outgoing; Tue, 12 Nov 1996 13:11:13 -0500 (EST) To: IETF-Announce:;;;;@tis.com@tis.com;;; cc: ipsec@tis.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-hmac-md5-01.txt Date: Tue, 12 Nov 1996 11:52:19 -0500 Message-ID: <9611121152.aa23440@ietf.org> Sender: owner-ipsec@ex.tis.com Precedence: list --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : HMAC: Keyed-Hashing for Message Authentication Author(s) : H. Krawczyk, M. Bellare, R. Canetti Filename : draft-ietf-ipsec-hmac-md5-01.txt Pages : 8 Date : 11/08/1996 This document describes HMAC, a mechanism for message authentication using cryptographic hash functions. HMAC can be used with any iterative cryptographic hash function, e.g., MD5, SHA-1, in combination with a secret shared key. The cryptographic strength of HMAC depends on the properties of the underlying hash function. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-hmac-md5-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-hmac-md5-01.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-hmac-md5-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961108101246.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-hmac-md5-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-hmac-md5-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961108101246.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Tue Nov 12 20:39:27 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA21453 for ipsec-outgoing; Tue, 12 Nov 1996 20:36:15 -0500 (EST) Message-Id: <199611130138.RAA00770@red.ipsilon.com> X-Mailer: exmh version 1.6.4 10/10/95 To: karn@qualcomm.com cc: smb@research.att.com, ipsec@tis.com Subject: Re: compression and encryption In-reply-to: Your message of "Tue, 05 Nov 1996 15:24:00 PST." <m0vKuqt-000MF6C@laptop> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 12 Nov 1996 17:38:41 -0800 From: Greg Minshall <minshall@ipsilon.com> Sender: owner-ipsec@ex.tis.com Precedence: list Phil, > (where header overhead is most significant) are now done with > intelligent local agents. Examples include email, netnews and web > surfing. Most of these agents speak various client/server protocols > over the wire with much larger average packet sizes as compared to > character-at-a-time telnet. This makes header overhead much less > significant. I think there continue to be protocols (RTP comes to mind) in which the header:payload ratio tends to be too high (even on 28.8 links). I'm not arguing that we need compression in ipsec; i'm just making the point that *compression* isn't necessarily a dead end, even in today's internet. Greg From owner-ipsec Wed Nov 13 13:22:28 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA23213 for ipsec-outgoing; Wed, 13 Nov 1996 13:13:54 -0500 (EST) Date: Wed, 13 Nov 96 10:12:00 PST From: John H Wilson <John_H_Wilson@ccm.jf.intel.com> Message-ID: <Wed, 13 Nov 96 10:15:08 PST_3@ccm.hf.intel.com> To: ipsec@tis.com Subject: Re-keying RTP streams Sender: owner-ipsec@ex.tis.com Precedence: list In H.323 (A/V conferencing as defined by the ITU), the media streams are transported by RTP; each stream also having a corresponding RTCP channel. Both the RTP and the RTCP channels are (of course) unreliable. H.323 also has a reliable (TCP) control channel (H.245) which is used to set up the RTP/RTCP channels and to control the conference. This channel remains open for the duration. [In a multipoint conference, each endpoint has a separate H.245 channel to the Conference Controller (the MC), and the RTP/RTP channels are multicast. In general, the H.245 channel cannot be used to communicate amongst endpoints; between transmitter and receivers]. In extending H.323 to provide private communications, the H.245 channel becomes secure (using TLS), and the security parameters for an RTP channel [the RTCP channel is not encrypted] are negotiated on it(them). In particular, the keys for the RTP channel are distributed on the H.245 channel(s) by the MC. All before thr RTP/RTCP sessions are established. The problem arises when the MC needs to distribute fresh keys after some period (or because the old key has been compromised for some reason). There's no problem in distributing the new keys (this is done on the reliable, secure H.245 channel). But how should the Transmitter and Receiver (or multiple receivers, in the multicast case) synchronize on the new key? The H.245 channel cannot be used for this purpose, since it does not (at least in the multipoint case) connect the transmitter to all receivers. We are left with just the RTP and RTCP channels. The RTP headers contain both sequence numbers and timestamps. There are two proposals: 1. There is a bit in all RTCP packets which flips when a new key starts being used on the RTP stream (and remains in the new state until the next key change). The first packet of the new state also contains the sequence number of the RTP stream at which the new key starts to apply. (This packet could be sent several times). A receiver will always see the bit flip but, if it misses the sequence number, it can immediately start using the new key; some number of RTP packets may have been indecipherable before this point. 2. The bit (as described above) would be in the RTP header (probably requiring an extended header). The receivers would change key as soon as they see the bit flip. I would very much like to hear opinions on these solutions, but preferrably, better proposals. john_h_wilson@ccm.jf.intel.com From owner-ipsec Wed Nov 13 20:42:15 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA24078 for ipsec-outgoing; Wed, 13 Nov 1996 20:40:41 -0500 (EST) Date: Wed, 13 Nov 1996 17:42:07 -0800 (PST) From: Phil Karn <karn@qualcomm.com> Message-Id: <199611140142.RAA14477@servo.qualcomm.com> To: minshall@ipsilon.com CC: smb@research.att.com, ipsec@tis.com In-reply-to: <199611130138.RAA00770@red.ipsilon.com> (message from Greg Minshall on Tue, 12 Nov 1996 17:38:41 -0800) Subject: Re: compression and encryption Sender: owner-ipsec@ex.tis.com Precedence: list >I think there continue to be protocols (RTP comes to mind) in which the >header:payload ratio tends to be too high (even on 28.8 links). I'm not >arguing that we need compression in ipsec; i'm just making the point that >*compression* isn't necessarily a dead end, even in today's internet. In its present form, VJ header compression only works for TCP/IP. There are some proposals for UDP/IP header compression, but I don't think they're widely deployed. The fundamental problem with any real time application over IP is the hard tradeoff that has to be made between header overhead and store-and-forward delay. This is a very difficult tradeoff, and systems where it is really important (like digital cellular) are designed from the ground up along very different lines. It may well be that it will never be possible to build one integrated network that can handle both realtime and nonrealtime traffic with an acceptable degree of efficiency and delay performance for both. Phil From owner-ipsec Wed Nov 13 20:55:19 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA24092 for ipsec-outgoing; Wed, 13 Nov 1996 20:55:10 -0500 (EST) Message-Id: <199611140157.RAA05553@cornpuffs.cisco.com> From: rja@cisco.com (Ran Atkinson) Date: Wed, 13 Nov 1996 17:57:00 PST X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: ipsec@tis.com Subject: Combined ESP transform Sender: owner-ipsec@ex.tis.com Precedence: list The Combined ESP transform completed its WG Last Call. There appears to be smooth consensus that it should advance to Proposed Standard and that RFC-1829 be moved to Historic status at the time the Combined ESP transform is published as a standards-track RFC. Ran Atkinson rja@cisco.com Paul Lambert palamber@us.oracle.com co-chairs, IP Security WG -- From owner-ipsec Thu Nov 14 09:57:11 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA24690 for ipsec-outgoing; Thu, 14 Nov 1996 09:54:09 -0500 (EST) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;;@tis.com@tis.com;;; cc: ipsec@tis.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-arch-sec-01.txt Date: Thu, 14 Nov 1996 09:27:10 -0500 Message-ID: <9611140927.aa04031@ietf.org> Sender: owner-ipsec@ex.tis.com Precedence: list --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : Security Architecture for the Internet Protocol Author(s) : R. Atkinson Filename : draft-ietf-ipsec-arch-sec-01.txt Pages : 24 Date : 11/12/1996 This memo describes the security protocols for IP version 4 (IPv4) and IP version 6 (IPv6) and the services that they provide. Each security protocol is specified in a separate document. This document also describes key management requirements for systems implementing these security protocols. This document is not an overall Security Architecture for the Internet; it addresses only IP-layer security. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-arch-sec-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-arch-sec-01.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-arch-sec-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961112150209.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-arch-sec-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-arch-sec-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961112150209.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Thu Nov 14 10:53:04 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA24787 for ipsec-outgoing; Thu, 14 Nov 1996 10:52:39 -0500 (EST) Message-ID: <01BBD211.132E50A0@webster.unety.net> From: Jim Fleming <JimFleming@unety.net> To: "'Phil Karn'" <karn@qualcomm.com>, "minshall@ipsilon.com" <minshall@ipsilon.com> Cc: "ipsec@tis.com" <ipsec@tis.com>, "smb@research.att.com" <smb@research.att.com> Subject: RE: compression and encryption Date: Thu, 14 Nov 1996 09:49:04 -0600 Sender: owner-ipsec@ex.tis.com Precedence: list On Wednesday, November 13, 1996 11:42 AM, Phil Karn[SMTP:karn@qualcomm.com] wrote: <snip> @ @ It may well be that it will never be possible to build one integrated @ network that can handle both realtime and nonrealtime traffic with an @ acceptable degree of efficiency and delay performance for both. @ Phil, In my opinion, I think that depends on how you define "integrated". If everyone assumes that the flat addressing and equal peer model of the Internet is the only way to scale the system, then I would agree with you. Imagine if everyone on the "toll" telephone network was allowed to plug everything from a phone, to a PBX, to a 5ESS into the network, this model would have problems scaling and being properly "integrated". In my opinion, the existing IPv4 network needs to be migrated to become a hardened, centralized, highly-reliable, "core" that primarily provides two things: 1. Low-cost bit transport to many regions of the world. 2. A distributed DNS system for mapping symbolic names to binary quantities (a.k.a. DNS). Once this "core" is stable it can be made more secure by encouraging the migration of users to better integrated layers which can designed around the edges of the core. The layers can be engineered based on "application" requirements as opposed to transport requirements. After it becomes more clear what the application requirements are (based on customer demands), the core can be evolved to more efficiently handle the outer layers. This type of integration assumes a separation of the transport core from the application layers. In my opinion, this can be viewed as "one" network, although I can see how some people might view it as more than one. -- Jim Fleming UNETY Systems, Inc. Naperville, IL e-mail: JimFleming@unety.net JimFleming@unety.net.s0.g0 (EDNS/IPv8) From owner-ipsec Thu Nov 14 13:44:25 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA24949 for ipsec-outgoing; Thu, 14 Nov 1996 13:40:03 -0500 (EST) From: Michael Richardson <mcr@sandelman.ottawa.on.ca> Message-Id: <199611141840.NAA08261@lox.sandelman.ottawa.on.ca> Subject: Re: compression and encryption To: JimFleming@unety.net (Jim Fleming) Date: Thu, 14 Nov 1996 13:40:18 -0500 (EST) Cc: ipsec@tis.com In-Reply-To: <01BBD211.132E50A0@webster.unety.net> from "Jim Fleming" at Nov 14, 96 09:49:04 am X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-ipsec@ex.tis.com Precedence: list > In my opinion, I think that depends on how you define "integrated". > > If everyone assumes that the flat addressing and equal peer model > of the Internet is the only way to scale the system, then I would > agree with you. It is the most democratic and the hardest to regulate and thus the safest from the influence of political and financial powers. No matter what the "core" does there are those of us that will stick to the tools we can control rather recreate the telephone system. There is a group of us in Ottawa that is trying to wein our community network away from the telephone system to wireless technology. From owner-ipsec Thu Nov 14 15:07:18 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA25030 for ipsec-outgoing; Thu, 14 Nov 1996 15:03:32 -0500 (EST) Message-ID: <01BBD234.678C4940@webster.unety.net> From: Jim Fleming <JimFleming@unety.net> To: "'Michael Richardson'" <mcr@sandelman.ottawa.on.ca> Cc: "ipsec@tis.com" <ipsec@tis.com> Subject: RE: compression and encryption Date: Thu, 14 Nov 1996 14:01:58 -0600 Sender: owner-ipsec@ex.tis.com Precedence: list On Thursday, November 14, 1996 7:40 AM, Michael Richardson[SMTP:mcr@sandelman.ottawa.on.ca] wrote: @ > In my opinion, I think that depends on how you define "integrated". @ > @ > If everyone assumes that the flat addressing and equal peer model @ > of the Internet is the only way to scale the system, then I would @ > agree with you. @ @ It is the most democratic and the hardest to regulate and thus @ the safest from the influence of political and financial powers. Yes, and that same attribute can be enjoyed by the outer layers. Just because there is a Legacy Core, control does not, naturally, implode into the center. @ No matter what the "core" does there are those of us that will @ stick to the tools we can control rather recreate the telephone @ system. There is a group of us in Ottawa that is trying to wein our @ community network away from the telephone system to wireless technology. @ Yes, in an ideal world, the core is optical or wireless or a combination of the two, and there is very little there. I would offer that the current core is only scaffolding to be used to provide a place to "stand" while the next layers are built. Once the next layers are worked out, the core can be phased out and eventually removed. Imagine taking a ballon and covering it with wet plaster. Once the plaster drys, you can stick a pin in the balloon and poof, the core disappears, but the plaster remains. Once you have that shell structure, then you continue to build outward, not inward. Optical sensors can be drilled down through the thin plaster to be able to "see" all of the other sites being built on the other side of the plaster shell. Just think, if the Earth were built that way, you might have a nice line-of-sight connection to Australia or an Island in the Caribbean. As it stands now, you still have to contend with gravity and the shape and structure of the Earth. Of course, if we could all just figure out how to achieve a low orbit with wireless connections between the sites, then the Earth could be turned into a nature preserve where we vacation when we are not "working" on our communication network. ..back to work...;-) -- Jim Fleming UNETY Systems, Inc. Naperville, IL e-mail: JimFleming@unety.net JimFleming@unety.net.s0.g0 (EDNS/IPv8) From owner-ipsec Thu Nov 14 20:15:15 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA25280 for ipsec-outgoing; Thu, 14 Nov 1996 20:13:05 -0500 (EST) Date: Thu, 14 Nov 1996 17:09:52 -0800 (PST) From: Phil Karn <karn@qualcomm.com> Message-Id: <199611150109.RAA28123@servo.qualcomm.com> To: JimFleming@unety.net CC: minshall@ipsilon.com, ipsec@tis.com, smb@research.att.com In-reply-to: <01BBD211.132E50A0@webster.unety.net> (message from Jim Fleming on Thu, 14 Nov 1996 09:49:04 -0600) Subject: RE: compression and encryption Sender: owner-ipsec@ex.tis.com Precedence: list >In my opinion, I think that depends on how you define "integrated". By "integrated" I mean "have a common network-layer protocol". This includes addressing. It does not include directory services, physical media, transport layer protocol, etc. In the case of the Internet, it means just IP (and perhaps ICMP). IP is *the* protocol that defines the Internet. The fundamental difference between a voice network (even a digital one) and a computer network is most clear in the network layer design. The limitations of the traditional circuit-switched telephony network for computer networking are well known, as they led to the creation of the Internet. And conversely, there are limitations of the Internet for conversational voice telephony. A lot of people dwell on the guaranteed service aspects of voice, and yes this is an issue -- but it's one that's likely to be solved by various real time protocols. A much more fundamental issue is the efficiency/delay tradeoff of using a connectionless network protocol for conversational voice. As speech coders get better and better, fewer bits have to be sent per unit time to provide good speech quality. Since people have a definite limit to how much propagation delay they can tolerate, this means smaller and smaller packets. They are now so small that the IP header overhead is now very significant. For example, the variable-rate vocoder we use in CDMA digital cellular generates one of 4 sizes of frames every 20 ms, and the largest of these is only 171 bits. That's only slightly larger than a 20-byte IP header (and you thought ATM frames were tiny). So you have a hard choice to make between taking a rather severe hit on overhead or bunching up packets and increasing delay as a result. Yes, various header compression schemes could be used over slow links when assumptions can be made about the lack of reordering, but these schemes aren't likely to work in the Internet as a whole. All this makes me believe that we will have separate network layer protocols for computer networking and conversational voice for some time. They may each pick up attributes of the other, but I doubt that just one will take over -- unless connectionless networks get so fast and cheap (or conversational voice becomes so unimportant) that efficiency becomes unimportant. This may happen someday on fiber, but it's unlikely to happen on the radio channels I work with. Phil From owner-ipsec Tue Nov 19 10:26:17 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA00752 for ipsec-outgoing; Tue, 19 Nov 1996 10:13:49 -0500 (EST) Message-Id: <2.2.32.19961119152137.00bbec34@mailserv-H.ftp.com> X-Sender: naganand@mailserv-H.ftp.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 19 Nov 1996 10:21:37 -0500 To: ipsec@tis.com From: Naganand Doraswamy <naganand@ftp.com> Subject: AH in IPv6 Sender: owner-ipsec@ex.tis.com Precedence: bulk In case of IPv6, if the packet were to fragemented on the end host, do we calculate AH before fragmentation or after fragmentation? RFC says that AH is calculated before fragmentation on the sending side and after reassembly on the receiving side. I guess it is possible to calculate AH after fragmentation as the packets are not fragmented by the intermediate routers in case of IPv6 and wanted to clarify which is the right thing to do. Am I correct in saying that AH is calculated before fragmentation on sending side and after reassembly on the receiving side even in IPv6? Thanks, --Naganand ---------------------------------------------------------------- naganand@ftp.com Tel #: (508)684-6743 (O) From owner-ipsec Tue Nov 19 11:16:51 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA00984 for ipsec-outgoing; Tue, 19 Nov 1996 11:14:50 -0500 (EST) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;;@tis.com@tis.com;;; cc: ipsec@tis.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-isakmp-oakley-01.txt Date: Tue, 19 Nov 1996 10:01:15 -0500 Message-ID: <9611191001.aa15589@ietf.org> Sender: owner-ipsec@ex.tis.com Precedence: bulk --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : The resolution of ISAKMP with Oakley Author(s) : D. Harkins, D. Carrel Filename : draft-ietf-ipsec-isakmp-oakley-01.txt Pages : 27 Date : 10/18/1996 [MSST96] (ISAKMP) provides a framework for authentication and key exchange but does not define them. ISAKMP is designed to be key exchange independant; that is, it is designed to support many different key exchanges. [Orm96] (Oakley) describes a series of key exchanges-- called "modes"-- and details the services provided by each (e.g. perfect forward secrecy for keys, identity protection, and authentication). This document describes a proposal for using the Oakley Key Exchange Protocol in conjunction with ISAKMP to obtain authenticated keying material for use with ISAKMP, and for other security associations such as AH and ESP for the IETF IPsec DOI. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-isakmp-oakley-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-isakmp-oakley-01.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-isakmp-oakley-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961118135721.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-isakmp-oakley-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-isakmp-oakley-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961118135721.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Tue Nov 19 11:16:54 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA00983 for ipsec-outgoing; Tue, 19 Nov 1996 11:14:49 -0500 (EST) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;;@tis.com@tis.com;;; cc: ipsec@tis.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ipsec-ipsec-doi-00.txt Date: Tue, 19 Nov 1996 10:01:09 -0500 Message-ID: <9611191001.aa15568@ietf.org> Sender: owner-ipsec@ex.tis.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : The Internet IP Security Domain of Interpretation for ISAKMP Author(s) : D. Piper Filename : draft-ipsec-ipsec-doi-00.txt Pages : 15 Date : 11/18/1996 The Internet Security Association and Key Management Protocol (ISAKMP) defines a framework for security association management and cryptographic key establishment for the Internet. This framework consists of defined exchanges and processing guidelines that occur within a given Domain of Interpretation (DOI). This document details the Internet IP Security DOI, which is defined to cover the IP security protocols that use ISAKMP to negotiate their security associations. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ipsec-ipsec-doi-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ipsec-ipsec-doi-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ipsec-ipsec-doi-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961118135339.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ipsec-ipsec-doi-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ipsec-ipsec-doi-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961118135339.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Tue Nov 19 14:44:31 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA01732 for ipsec-outgoing; Tue, 19 Nov 1996 14:38:31 -0500 (EST) From: dan.mcdonald@eng.sun.com (Dan McDonald) Message-Id: <199611191926.LAA26149@kebe.eng.sun.com> Subject: Re: AH in IPv6 To: naganand@ftp.com Date: Tue, 19 Nov 1996 11:26:36 -0800 (PST) Cc: ipsec@tis.com In-Reply-To: <2.2.32.19961119152137.00bbec34@mailserv-H.ftp.com> from "Naganand Doraswamy" at Nov 19, 96 10:21:37 am X-Mailer: ELM [version 2.4 PL21] Content-Type: text Sender: owner-ipsec@portal.ex.tis.com Precedence: bulk > In case of IPv6, if the packet were to fragemented on the end host, do we > calculate AH before fragmentation or after fragmentation? RFC says that AH > is calculated before fragmentation on the sending side and after reassembly > on the receiving side. I guess it is possible to calculate AH after > fragmentation as the packets are not fragmented by the intermediate routers > in case of IPv6 and wanted to clarify which is the right thing to do. Stick with the spec! Authentication before fragmentation is CLEARLY the right thing to do. All sorts of trickinesses happen if you authenticate fragments. Think about fragment size if you don't know the SA before fragmenting. If I have the SA a priori, I might as well do it. If I don't have an SA, I shouldn't fragment because I don't know what algorithm key management (or algorithm discovery for you in-line keying folks) will negotiate. I can't determine the fragment size in that case because I don't necessarily know the size of the AH. > Am I correct in saying that AH is calculated before fragmentation on sending > side and after reassembly on the receiving side even in IPv6? Absolutely correct! -- Daniel L. McDonald | Mail: danmcd@eng.sun.com Phone: (415) 786-6815 + Software Engineer | *** My opinions aren't necessarily Sun's opinions! *** | SunSoft Internet | "rising falling at force ten | Engineering| we twist the world and ride the wind" - Rush + From owner-ipsec Wed Nov 20 10:37:27 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA04194 for ipsec-outgoing; Wed, 20 Nov 1996 10:31:54 -0500 (EST) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;;@tis.com@tis.com;;; cc: ipsec@tis.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ipsec-ipsec-doi-01.txt Date: Wed, 20 Nov 1996 09:56:50 -0500 Message-ID: <9611200956.aa14139@ietf.org> Sender: owner-ipsec@ex.tis.com Precedence: bulk --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : The Internet IP Security Domain of Interpretation for ISAKMP Author(s) : D. Piper Filename : draft-ipsec-ipsec-doi-01.txt Pages : 15 Date : 11/19/1996 The Internet Security Association and Key Management Protocol (ISAKMP) defines a framework for security association management and cryptographic key establishment for the Internet. This framework consists of defined exchanges and processing guidelines that occur within a given Domain of Interpretation (DOI). This document details the Internet IP Security DOI, which is defined to cover the IP security protocols that use ISAKMP to negotiate their security associations. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ipsec-ipsec-doi-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ipsec-ipsec-doi-01.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ipsec-ipsec-doi-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961119101447.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ipsec-ipsec-doi-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ipsec-ipsec-doi-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961119101447.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Wed Nov 20 10:37:27 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA04192 for ipsec-outgoing; Wed, 20 Nov 1996 10:31:53 -0500 (EST) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;;@tis.com@tis.com;;; From: Internet-Drafts@ietf.org cc: ipsec@tis.com Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-mcdonald-pf-key-v2-00.txt Date: Wed, 20 Nov 1996 09:57:41 -0500 Message-ID: <9611200957.aa14213@ietf.org> Sender: owner-ipsec@ex.tis.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : PF_KEY Key Management API, Version 2 Author(s) : D. McDonald, C. Metz, B Phan Filename : draft-mcdonald-pf-key-v2-00.txt Pages : 43 Date : 11/19/1996 This memo documents a user-to-kernel interface for key management applications. It is derived from the 4.x BSD routing socket, and it operates in a very similar fasion. This document is informational, and not meant to specify a standard. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-mcdonald-pf-key-v2-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-mcdonald-pf-key-v2-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-mcdonald-pf-key-v2-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961119151230.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-mcdonald-pf-key-v2-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-mcdonald-pf-key-v2-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961119151230.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Wed Nov 20 10:55:45 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA04298 for ipsec-outgoing; Wed, 20 Nov 1996 10:54:11 -0500 (EST) Date: Wed, 20 Nov 1996 10:54:11 -0500 (EST) From: owner-ipsec@ex.tis.com Message-Id: <199611201521.RAA02438@del.tla.org> X-Mailer: exmh version 1.6.2 7/18/95 To: linux-ipsec@clinet.fi Cc: ipsec@tis.com Subject: New release of IPSEC for Linux. Reply-To: ji@hol.gr Organization: La maison qui rend fou. Mime-Version: 1.0 Content-Type: application/pgp; format=mime; x-action=signclear; x-originator=2D3EEAD5 Content-Transfer-Encoding: 7bit Date: Wed, 20 Nov 1996 17:21:21 +0200 From: John Ioannidis <ji@hol.gr> Sender: owner-ipsec@portal.ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Content-Type: text/plain; charset=us-ascii Release 0.3 is out. Some bug fixes, more examples, better release engineering. It should appear in ftp://ftp.funet.fi/pub/unix/security/net/ip/ in a few hours (theoretically, shortly after 96/11/21 03:05 UTC). The impatient can get it from http://users.prometheus.gr/~ji/ipsec/. Read README.1st first. Get ipsec-0.3.tar.gz. Verify it against the PGP signature in ipsec-0.3.pgp. As usual, report any problems to me (ji@hol.gr) /ji -----BEGIN PGP SIGNATURE----- Version: 2.6.i iQCVAgUBMpMh78+A0YctPurVAQF/gAQAownuVE9TsMAnoS96XfCgMM1td3kQXziN JRNDYmcODoMKR7+R8rSDSviAYKq9kzW+XmRM57eSAOTqec+rAxwfSv9NBQAT4Xxn n2r5H0N/8VHq2qEETvxBiNbACpH3754vj178Jm+fd3j5o3Wj6c/lcOKMI2b7GxBN 52yRsM2eS2c= =ceb6 -----END PGP SIGNATURE----- From owner-ipsec Wed Nov 20 10:57:31 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA04335 for ipsec-outgoing; Wed, 20 Nov 1996 10:56:11 -0500 (EST) Date: Wed, 20 Nov 1996 10:56:11 -0500 (EST) From: owner-ipsec@ex.tis.com Message-Id: <199611201536.RAA02515@del.tla.org> X-Mailer: exmh version 1.6.2 7/18/95 To: linux-ipsec@clinet.fi Cc: ipsec@tis.com Subject: Re: New release of IPSEC for Linux. In-Reply-To: Your message of "Wed, 20 Nov 1996 17:21:21 +0200." <199611201521.RAA02438@del.tla.org> Reply-To: ji@hol.gr Organization: La maison qui rend fou. Mime-Version: 1.0 Content-Type: application/pgp; format=mime; x-action=signclear; x-originator=2D3EEAD5 Content-Transfer-Encoding: 7bit Date: Wed, 20 Nov 1996 17:35:58 +0200 From: John Ioannidis <ji@hol.gr> Sender: owner-ipsec@portal.ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Content-Type: text/plain; charset=us-ascii > The impatient can get it from http://users.prometheus.gr/~ji/ipsec/. I meant http://users.hol.gr/~ji/ipsec/. Sorry about that! /ji -----BEGIN PGP SIGNATURE----- Version: 2.6.i iQCVAgUBMpMlXM+A0YctPurVAQEu6gQAroCFZ/xXI981YA44OnpCXhTQ0JYk+dtA 17ctIgeh+KQgB8oUv0po9cL2d50w/sHHNrYUYLKe6vtFmpBgdqt7c5E7FmTJL8f4 k6HRGxC1/l+cc0rO/d/5Zjnc53V12MOlk5XvplWu8PsHaIZA8dt9P+PRDSUhc2QN lkrLlHzIZfE= =eO3w -----END PGP SIGNATURE----- From owner-ipsec Wed Nov 20 14:00:04 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA04945 for ipsec-outgoing; Wed, 20 Nov 1996 13:56:46 -0500 (EST) Date: Wed, 20 Nov 96 10:56:00 PST From: John H Wilson <John_H_Wilson@ccm.jf.intel.com> Message-ID: <Wed, 20 Nov 96 10:58:08 PST_9@ccm.jf.intel.com> To: owner-ipsec@portal.ex.tis.com cc: ipsec@tis.com Subject: Re: I-D ACTION:draft-ipsec-ipsec-doi-01.txt Sender: owner-ipsec@ex.tis.com Precedence: bulk Text item: I believe the name should be: draft-ietf-ipsec-ipsec-doi-01.txt ______________________________ Reply Separator _________________________________ Subject: I-D ACTION:draft-ipsec-ipsec-doi-01.txt Author: owner-ipsec@portal.ex.tis.com at SMTPGATE Date: 11/20/96 9:56 AM --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : The Internet IP Security Domain of Interpretation for ISAKMP Author(s) : D. Piper Filename : draft-ipsec-ipsec-doi-01.txt Pages : 15 Date : 11/19/1996 The Internet Security Association and Key Management Protocol (ISAKMP) defines a framework for security association management and cryptographic key establishment for the Internet. This framework consists of defined exchanges and processing guidelines that occur within a given Domain of Interpretation (DOI). This document details the Internet IP Security DOI, which is defined to cover the IP security protocols that use ISAKMP to negotiate their security associations. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ipsec-ipsec-doi-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ipsec-ipsec-doi-01.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ipsec-ipsec-doi-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961119101447.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ipsec-ipsec-doi-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ipsec-ipsec-doi-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961119101447.I-D@ietf.org> --OtherAccess-- --NextPart-- Text item: External Message Header The following mail header is for administrative use and may be ignored unless there are problems. ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. Precedence: bulk Sender: owner-ipsec@ex.tis.com Message-ID: <9611200956.aa14139@ietf.org> Date: Wed, 20 Nov 1996 09:56:50 -0500 Subject: I-D ACTION:draft-ipsec-ipsec-doi-01.txt Reply-to: Internet-Drafts@ietf.org From: Internet-Drafts@ietf.org cc: ipsec@tis.com To: IETF-Announce:;;;;;;@tis.com@tis.com;;;;;;;;;;;;;;;;;;; Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA041 94 for ipsec-outgoing; Wed, 20 Nov 1996 10:31:54 -0500 (EST) Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mailbag .jf.intel.com (8.8.3/8.7.3) with ESMTP id KAA02561 for <John_H_Wilson@ccm.jf.int el.com>; Wed, 20 Nov 1996 10:22:59 -0800 (PST) Received: from mailbag.jf.intel.com (root@mailbag.jf.intel.com [134.134.248.4]) by relay.jf.intel.com (8.8.2/8.7.3) with ESMTP id KAA00859 for <John_H_Wilson@cc m.jf.intel.com>; Wed, 20 Nov 1996 10:20:26 -0800 (PST) Return-Path: owner-ipsec@portal.ex.tis.com From owner-ipsec Wed Nov 20 14:04:34 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA04958 for ipsec-outgoing; Wed, 20 Nov 1996 14:03:16 -0500 (EST) Message-ID: <3293566E.2781@cs.umass.edu> Date: Wed, 20 Nov 1996 14:05:19 -0500 From: Lewis McCarthy <lmccarth@cs.umass.edu> Organization: Theoretical Computer Science Group, UMass-Amherst, <URL:http://www.cs.umass.edu/~thtml/> X-Mailer: Mozilla 3.0 (X11; I; OSF1 V3.0 alpha) MIME-Version: 1.0 To: Internet-Drafts@ietf.org CC: ipsec@tis.com Subject: Re: I-D ACTION:draft-ipsec-ipsec-doi-01.txt References: <9611200956.aa14139@ietf.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Internet-Drafts@ietf.org wrote: [...] > Title : The Internet IP Security Domain of Interpretation for > ISAKMP > Author(s) : D. Piper > Filename : draft-ipsec-ipsec-doi-01.txt > Pages : 15 > Date : 11/19/1996 [...] > A URL for the Internet-Draft is: > ftp://ds.internic.net/internet-drafts/draft-ipsec-ipsec-doi-01.txt There's a "-ietf" missing from the draft name -- it actually appears to be: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-ipsec-doi-01.txt -Lewis <lmccarth@cs.umass.edu> From owner-ipsec Thu Nov 21 04:48:01 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id EAA05856 for ipsec-outgoing; Thu, 21 Nov 1996 04:41:24 -0500 (EST) Date: Thu, 21 Nov 1996 10:42:15 +0100 From: saiz@gc.ssr.upm.es ("LUIS SAIZ GIMENO") Message-Id: <199611210942.AA25881@orfeo.gc.ssr.upm.es> To: ipsec@tis.com Subject: Any work in IPsec multicast key management? Sender: owner-ipsec@ex.tis.com Precedence: bulk I would like to know if there is some work in progress in multicast/anycast key management in this WG. Any idea about which kind of cryptographic protocol is suitable to be adopted? TIA. Luis Saiz Gimeno saiz@gc.ssr.upm.es Grupo de Circuitos, SSR, Polytechnical University of Madrid --------------------------------------------------------------------- Protocol cryptanalysis is essentially formalized paranoia. -- G. Simmons. --------------------------------------------------------------------- From owner-ipsec Thu Nov 21 10:23:13 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA06664 for ipsec-outgoing; Thu, 21 Nov 1996 10:19:39 -0500 (EST) Message-Id: <2.2.32.19961121152124.00af7be4@pop.hq.tis.com> X-Sender: freeves@pop.hq.tis.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 21 Nov 1996 10:21:24 -0500 To: ipsec@tis.com From: owner-ipsec@tis.com (by way of Frank Reeves <freeves@pop.hq.tis.com>) Subject: BOUNCE ipsec@portal.ex.tis.com: Non-member submission from [Internet-Drafts@ietf.org] Sender: owner-ipsec@ex.tis.com Precedence: bulk
- proposed IPSEC changes/extensions Stephen Kent
- Re: proposed IPSEC changes/extensions David Wagner
- Re: proposed IPSEC changes/extensions Ran Atkinson
- Re: proposed IPSEC changes/extensions Hilarie Orman
- Re: proposed IPSEC changes/extensions pau
- Re: proposed IPSEC changes/extensions Michael Sabin
- Re: proposed IPSEC changes/extensions Stephen Kent
- Re: proposed IPSEC changes/extensions pau
- Re: proposed IPSEC changes/extensions Bill Sommerfeld
- Re: proposed IPSEC changes/extensions pau
- Re: proposed IPSEC changes/extensions Santeri Paavolainen
- Re: proposed IPSEC changes/extensions Rodney Thayer
- Re: proposed IPSEC changes/extensions Santeri Paavolainen
- Re: proposed IPSEC changes/extensions Stephen Kent
- Re: proposed IPSEC changes/extensions David Wagner
- Re: proposed IPSEC changes/extensions Steven Bellovin
- Re: proposed IPSEC changes/extensions Michael Sabin
- Re: proposed IPSEC changes/extensions John Gilmore