Re: proposed IPSEC changes/extensions

[John Gilmore <[e-mail]>]

> 							 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: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-ipsec-esp-3des-md5-00.txt
Date: Tue, 05 Nov 1996 09:42:11 -0500
Message-ID:  <[e-mail]>
Sender: [e-mail]
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:  [e-mail]. 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="[e-mail]"

Content-Type: text/plain
Content-ID: <[e-mail]>

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: <[e-mail]>

--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: [e-mail]
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 <[e-mail]>
From: [e-mail] (Stephen Kent)
Subject: Re: proposed IPSEC changes/extensions
Cc: [e-mail]
Sender: [e-mail]
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 <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: ANNOUNCEMENT -- New majordomo server
Sender: [e-mail]
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
[e-mail].  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 [e-mail] 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=[e-mail]>
From: Greg Carter <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
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: [e-mail]
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
[e-mail]


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: <[e-mail]>
X-Authentication-Warning: toad.com: Host localhost [127.0.0.1] didn't use HELO protocol
To: [e-mail] (Stephen Kent)
cc: John Gilmore <[e-mail]>, [e-mail], [e-mail]
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 <[e-mail]>
Sender: [e-mail]
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: <[e-mail]>
X-Sender: [e-mail]
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: [e-mail]
From: [e-mail] (by way of "John C. Kelley" <[e-mail]>)
Subject: BOUNCE [e-mail]: Non-member submission from
  ["Donald E. Eastlake 3rd" <[e-mail]>]
Sender: [e-mail]
Precedence: list

Approved New.poised
Date: Tue, 5 Nov 1996 12:59:36 -0500 (EST)
From: "Donald E. Eastlake 3rd" <[e-mail]>
To: "John W. Stewart III" <[e-mail]>
Cc: [e-mail]
Subject: Re: The NomCom Selection 
In-Reply-To: <[e-mail]>
Message-Id: <[e-mail]>
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 <[e-mail]>
> To: William Allen Simpson <[e-mail]>
> Cc: [e-mail]
> 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     [phone](tel)     [e-mail]
   318 Acton Street        [phone](fax)     [e-mail]
Carlisle, MA 01741 USA     [phone](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=[e-mail]>
From: Greg Carter <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
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: [e-mail]
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
[e-mail]



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 <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>,
        "'[e-mail]'" <[e-mail]>
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=[e-mail]> 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 06 Nov 1996 14:31:13 -0800
From: Daniel Harkins <[e-mail]>
Sender: [e-mail]
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:  [e-mail]
Network Protocol Security, cisco Systems   |   phone:   [phone]
170 W. Tasman Drive                        |   fax:     [phone]
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: <[e-mail]>
X-Authentication-Warning: smb.research.att.com.research.att.com: smb owned process doing -bs
From: Steve Bellovin <[e-mail]>
To: [e-mail]
Subject: compression and encryption
Date: Wed, 06 Nov 1996 20:54:39 -0500
Sender: [e-mail]
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: <[e-mail]>
X-Sender: [e-mail]
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 <[e-mail]>
From: Rodney Thayer <[e-mail]>
Subject: Re: compression and encryption
Cc: [e-mail]
Sender: [e-mail]
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 <[e-mail]>       [phone]
               Sable Technology Corp, 246 Walnut St., Newton MA 02160 USA
               Fax: [phone]           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: <[e-mail]>
From: Leonard Samuelson <[e-mail]>
To: Rodney Thayer <[e-mail]>
Cc: Steve Bellovin <[e-mail]>, [e-mail]
Subject: Re: compression and encryption
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Reply-To: [e-mail] (Len Samuelson)
Sender: [e-mail]
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: <[e-mail]>
From: Bill Hunt <[e-mail]>
To: "[e-mail]" <[e-mail]>,
        "'Steve Bellovin'"
	 <[e-mail]>
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: [e-mail]
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:[e-mail]]
Sent: 	Wednesday, November 06, 1996 5:54 PM
To: 	[e-mail]
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: <[e-mail]>
From: Bill Hunt <[e-mail]>
To: Steve Bellovin <[e-mail]>,
        "'Rodney Thayer'"
	 <[e-mail]>
Cc: "[e-mail]" <[e-mail]>
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: [e-mail]
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:[e-mail]]
Sent: 	Thursday, November 07, 1996 9:12 AM
To: 	Steve Bellovin
Cc: 	[e-mail]
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=[e-mail]>
X-MS-TNEF-Correlator: <c=US%a=_%p=TimeStep_Corpora%l=[e-mail]>
From: Roy Pereira <[e-mail]>
To: "'isakmp-oakley'" <[e-mail]>, "'IPSEC'" <[e-mail]>
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: [e-mail]
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: <[e-mail]>
To: Rodney Thayer <[e-mail]>
cc: [e-mail]
Subject: Re: compression and encryption 
Date: Thu, 07 Nov 1996 21:13:04 -0500
From: Steven Bellovin <[e-mail]>
Sender: [e-mail]
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: <[e-mail]>
To: Bill Hunt <[e-mail]>
cc: "[e-mail]" <[e-mail]>
Subject: Re: compression and encryption 
Date: Thu, 07 Nov 1996 21:18:07 -0500
From: Steven Bellovin <[e-mail]>
Sender: [e-mail]
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: [e-mail] (W. Douglas Maughan)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail], [e-mail]
Subject: Re: S/WAN ISAKMP/Oakley testing...
Sender: [e-mail]
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 <[e-mail]>
X-Sender: iduncan@magnus2
Reply-To: Ian Duncan <[e-mail]>
To: Steven Bellovin <[e-mail]>
cc: [e-mail]
Subject: Re: compression and encryption 
In-Reply-To: <[e-mail]>
Message-ID: <Pine.GSO.3.93.961108095127.8864W-100000@magnus2>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
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 <[e-mail]>
     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 <[e-mail]>
Message-ID: <Fri, 08 Nov 96 08:15:02 [e-mail]>
To: [e-mail], [e-mail]
cc: [e-mail]
Subject: Re[2]: compression and encryption
Sender: [e-mail]
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:  [e-mail] 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: [e-mail]
From: Steven Bellovin <[e-mail]>
Date: Thu, 07 Nov 1996 21:13:04 -0500
Subject: Re: compression and encryption
cc: [e-mail]
To: Rodney Thayer <[e-mail]>
Message-Id: <[e-mail]>
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 <[e-mail]
el.com>; Thu, 7 Nov 1996 20:22:08 -0800 (PST)
Received: from mailbag.jf.intel.com ([e-mail] [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: [e-mail]

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: <[e-mail]>
To: John H Wilson <[e-mail]>
cc: [e-mail]
Subject: Re: Re[2]: compression and encryption 
Date: Fri, 08 Nov 1996 13:08:09 -0500
From: Steven Bellovin <[e-mail]>
Sender: [e-mail]
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: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Light Version 1.5.2
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: Steven Bellovin <[e-mail]>
From: Michael Sabin <[e-mail]>
Subject: Re: compression and encryption 
Cc: [e-mail]
Sender: [e-mail]
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: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Fri, 08 Nov 1996 14:11:14 -0800
To: Steve Bellovin <[e-mail]>
From: Bob Monsour <[e-mail]>
Subject: Re: compression and encryption
Cc: [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
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
[e-mail]

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 <[e-mail]>
To: [e-mail]
CC: [e-mail]
Reply-To: [e-mail]
In-reply-to: <[e-mail]>
	(message from Steve Bellovin on Wed, 06 Nov 1996 20:54:39 -0500)
Subject: Re: compression and encryption
Sender: [e-mail]
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:;;;;@[e-mail];;;
cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-ipsec-hmac-md5-01.txt
Date: Tue, 12 Nov 1996 11:52:19 -0500
Message-ID:  <[e-mail]>
Sender: [e-mail]
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:  [e-mail]. 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="[e-mail]"

Content-Type: text/plain
Content-ID: <[e-mail]>

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: <[e-mail]>

--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: <[e-mail]>
X-Mailer: exmh version 1.6.4 10/10/95
To: [e-mail]
cc: [e-mail], [e-mail]
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 <[e-mail]>
Sender: [e-mail]
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 <[e-mail]>
Message-ID: <Wed, 13 Nov 96 10:15:08 [e-mail]>
To: [e-mail]
Subject: Re-keying RTP streams
Sender: [e-mail]
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. 

[e-mail]






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 <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
CC: [e-mail], [e-mail]
In-reply-to: <[e-mail]> (message from Greg Minshall on Tue, 12 Nov 1996 17:38:41 -0800)
Subject: Re: compression and encryption
Sender: [e-mail]
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: <[e-mail]>
From: [e-mail] (Ran Atkinson)
Date: Wed, 13 Nov 1996 17:57:00 PST
X-Mailer: Mail User's Shell (7.2.5 10/14/92)
To: [e-mail]
Subject: Combined ESP transform
Sender: [e-mail]
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
[e-mail]

Paul Lambert
[e-mail]

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:;;;;@[e-mail];;;
cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-ipsec-arch-sec-01.txt
Date: Thu, 14 Nov 1996 09:27:10 -0500
Message-ID:  <[e-mail]>
Sender: [e-mail]
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:  [e-mail]. 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="[e-mail]"

Content-Type: text/plain
Content-ID: <[e-mail]>

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: <[e-mail]>

--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: <[e-mail]>
From: Jim Fleming <[e-mail]>
To: "'Phil Karn'" <[e-mail]>,
        "[e-mail]"
	 <[e-mail]>
Cc: "[e-mail]" <[e-mail]>,
        "[e-mail]"
	 <[e-mail]>
Subject: RE: compression and encryption
Date: Thu, 14 Nov 1996 09:49:04 -0600
Sender: [e-mail]
Precedence: list

On Wednesday, November 13, 1996 11:42 AM, Phil Karn[SMTP:[e-mail]] 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:
[e-mail]
[e-mail].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 <[e-mail]>
Message-Id: <[e-mail]>
Subject: Re: compression and encryption
To: [e-mail] (Jim Fleming)
Date: Thu, 14 Nov 1996 13:40:18 -0500 (EST)
Cc: [e-mail]
In-Reply-To: <[e-mail]> from "Jim Fleming" at Nov 14, 96 09:49:04 am
X-Mailer: ELM [version 2.4 PL25]
Content-Type: text
Sender: [e-mail]
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: <[e-mail]>
From: Jim Fleming <[e-mail]>
To: "'Michael Richardson'" <[e-mail]>
Cc: "[e-mail]" <[e-mail]>
Subject: RE: compression and encryption
Date: Thu, 14 Nov 1996 14:01:58 -0600
Sender: [e-mail]
Precedence: list

On Thursday, November 14, 1996 7:40 AM, Michael Richardson[SMTP:[e-mail]] 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:
[e-mail]
[e-mail].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 <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
CC: [e-mail], [e-mail], [e-mail]
In-reply-to: <[e-mail]> (message from Jim Fleming on Thu, 14 Nov 1996 09:49:04 -0600)
Subject: RE: compression and encryption
Sender: [e-mail]
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: <[e-mail]>
X-Sender: [e-mail]
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: [e-mail]
From: Naganand Doraswamy <[e-mail]>
Subject: AH in IPv6
Sender: [e-mail]
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
----------------------------------------------------------------
[e-mail]
Tel #: [phone] (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:;;;;@[e-mail];;;
cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-ipsec-isakmp-oakley-01.txt
Date: Tue, 19 Nov 1996 10:01:15 -0500
Message-ID:  <[e-mail]>
Sender: [e-mail]
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:  [e-mail]. 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="[e-mail]"

Content-Type: text/plain
Content-ID: <[e-mail]>

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: <[e-mail]>

--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:;;;;@[e-mail];;;
cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ipsec-ipsec-doi-00.txt
Date: Tue, 19 Nov 1996 10:01:09 -0500
Message-ID:  <[e-mail]>
Sender: [e-mail]
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:  [e-mail]. 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="[e-mail]"

Content-Type: text/plain
Content-ID: <[e-mail]>

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: <[e-mail]>

--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: [e-mail] (Dan McDonald)
Message-Id: <[e-mail]>
Subject: Re: AH in IPv6
To: [e-mail]
Date: Tue, 19 Nov 1996 11:26:36 -0800 (PST)
Cc: [e-mail]
In-Reply-To: <[e-mail]> from

"Naganand Doraswamy" at Nov 19, 96 10:21:37 am
X-Mailer: ELM [version 2.4 PL21]
Content-Type: text
Sender: [e-mail]
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: [e-mail]   Phone: [phone]        +
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:;;;;@[e-mail];;;
cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ipsec-ipsec-doi-01.txt
Date: Wed, 20 Nov 1996 09:56:50 -0500
Message-ID:  <[e-mail]>
Sender: [e-mail]
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:  [e-mail]. 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="[e-mail]"

Content-Type: text/plain
Content-ID: <[e-mail]>

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: <[e-mail]>

--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:;;;;@[e-mail];;;
From: [e-mail]
cc: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-mcdonald-pf-key-v2-00.txt
Date: Wed, 20 Nov 1996 09:57:41 -0500
Message-ID:  <[e-mail]>
Sender: [e-mail]
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:  [e-mail]. 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="[e-mail]"

Content-Type: text/plain
Content-ID: <[e-mail]>

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: <[e-mail]>

--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: [e-mail]
Message-Id: <[e-mail]>
X-Mailer: exmh version 1.6.2 7/18/95
To: [e-mail]
Cc: [e-mail]
Subject: New release of IPSEC for Linux.
Reply-To: [e-mail]
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 <[e-mail]>
Sender: [e-mail]
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 ([e-mail]).

/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: [e-mail]
Message-Id: <[e-mail]>
X-Mailer: exmh version 1.6.2 7/18/95
To: [e-mail]
Cc: [e-mail]
Subject: Re: New release of IPSEC for Linux. 
In-Reply-To: Your message of "Wed, 20 Nov 1996 17:21:21 +0200."
             <[e-mail]> 
Reply-To: [e-mail]
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 <[e-mail]>
Sender: [e-mail]
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 <[e-mail]>
Message-ID: <Wed, 20 Nov 96 10:58:08 [e-mail]>
To: [e-mail]
cc: [e-mail]
Subject: Re: I-D ACTION:draft-ipsec-ipsec-doi-01.txt
Sender: [e-mail]
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:  [e-mail] 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:  [e-mail]. 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="[e-mail]"

Content-Type: text/plain
Content-ID: <[e-mail]>

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: <[e-mail]>

--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: [e-mail]
Message-ID:  <[e-mail]>
Date: Wed, 20 Nov 1996 09:56:50 -0500
Subject: I-D ACTION:draft-ipsec-ipsec-doi-01.txt
Reply-to: [e-mail]
From: [e-mail]
cc: [e-mail]
To: IETF-Announce:;;;;;;@[e-mail];;;;;;;;;;;;;;;;;;;
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 <[e-mail]
el.com>; Wed, 20 Nov 1996 10:22:59 -0800 (PST)
Received: from mailbag.jf.intel.com ([e-mail] [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: [e-mail]

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: <[e-mail]>
Date: Wed, 20 Nov 1996 14:05:19 -0500
From: Lewis McCarthy <[e-mail]>
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: [e-mail]
CC: [e-mail]
Subject: Re: I-D ACTION:draft-ipsec-ipsec-doi-01.txt
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

[e-mail] 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	<[e-mail]>

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: [e-mail] ("LUIS SAIZ GIMENO")
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Any work in IPsec multicast  key management?
Sender: [e-mail]
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
	[e-mail]
	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: <[e-mail]>
X-Sender: [e-mail]
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: [e-mail]
From: [e-mail] (by way of Frank Reeves <[e-mail]>)
Subject: BOUNCE [e-mail]:    Non-member submission from
  [[e-mail]]   
Sender: [e-mail]
Precedence: bulk