[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Status of IPSEC Key Management

Perry E. Metzger wrote:
> > This is only if you do RSVP based on SPIs.  You can do RSVP based
> > on Master key IDs.
> I believe that the RSVP wanted a general mechanism, and not one tied
> to SKIP. Could you please accept that everyone on earth will not be
> using one key management facility and that the protocols must support
> this?
> Perry

Well, then let's get ahead with the current proposals, and move them on!
IMNSHO there are enough advocats for all of the current proposals, so lets
deploy the stuff and see what works. I do not remember SKIP as being
declared as the global solution to key management ever, quite on the
contrary. Others utter this claim much more readily.

And yes, I know we are all waiting for Jeff Schillers resolution on this
issue to appear. Altough this is a difficult task, I hope this will happen 
soon.

Germano


Message-Id: <3.0b15.32.19960911130321.00a00e68@pop3hub.is.chrysler.com>
Reply-To: rgm3@chrysler.com
X-Sender: rgm3@pop3hub.is.chrysler.com
X-Mailer: Windows Eudora Pro Version 3.0b15 (32)
Date: Wed, 11 Sep 1996 13:05:05 -0400
To: Hilarie Orman <ho@earth.hpc.org>, skrenta@osmosys.incog.com
From: Robert Moskowitz <rgm3@chrysler.com>
Subject: Re: Status of IPSEC Key Management
Cc: ipsec@TIS.COM
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk

At 03:21 PM 9/10/96 -0400, Hilarie Orman wrote:
>In the past Phil Karn made a compelling case for supporting 2400 baud
>connections, and header minimization is a significant concern there.
>Though such slow connections seemed humorous initially, it now seems that
>ubiquitous wireless connections over low power, low speed links might
>become a major component of the future Internet universe.

You would not be happening to be thinking about PDAs, would you?

And what about something that Phil's CEO said about a full IPsec capable
processor in the new Qualcomm cellular phones?


Robert Moskowitz
Chrysler Corporation
(810) 758-8212




Message-Id: <3.0b15.32.19960911125801.00b03008@pop3hub.is.chrysler.com>
Reply-To: rgm3@chrysler.com
X-Sender: rgm3@pop3hub.is.chrysler.com
X-Mailer: Windows Eudora Pro Version 3.0b15 (32)
Date: Wed, 11 Sep 1996 13:05:03 -0400
To: Steven Bellovin <smb@research.att.com>, 
    "C. Harald Koch" <chk@border.com>
From: Robert Moskowitz <rgm3@chrysler.com>
Subject: Re: bandwidth in the Internet 
Cc: ipsec@TIS.COM
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk

At 01:57 PM 9/10/96 -0400, Steven Bellovin wrote:
>
>	Assuming 45 bytes/ACK (40 + ~5 for PPP), you can get a maximum
>	of 80 ACK/sec through the backchannel. This means 160
>	packets/sec in the forward direction (TCP acks every second
>	segment); this yields a maximum bandwidth usage of 1.92Mbps
>	(using 1500 byte MTU). Only 1/5th the available bandwidth.
>
>Empirically, I get about a quarter of that -- modems have a moderately
>high fixed delay per packet.  Increasing my TCP window size ups
>throughput, I'm told.

Much of this is in the V.42bis logic.  Well since we are encrypting, modem
compression does not buy much.  Turn it off and check out the difference.
Of course if you do this, non-encrypted compressable data suffers
conciderably (unless you have a PPP level compression).

Of course the delay in the V.42 logic cannot be helped.  My experience is
you never want to run without V.42, even if you risk the 12 naks of death.


Robert Moskowitz
Chrysler Corporation
(810) 758-8212




Message-Id: <3.0b15.32.19960911125851.00b272e8@pop3hub.is.chrysler.com>
Reply-To: rgm3@chrysler.com
X-Sender: rgm3@pop3hub.is.chrysler.com
X-Mailer: Windows Eudora Pro Version 3.0b15 (32)
Date: Wed, 11 Sep 1996 13:05:04 -0400
To: Rich Skrenta <skrenta@osmosys.incog.com>, perry@piermont.com
From: Robert Moskowitz <rgm3@chrysler.com>
Subject: Re: Status of IPSEC Key Management
Cc: ipsec@TIS.COM
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk

At 11:23 AM 9/10/96 -0700, Rich Skrenta wrote:
>> Not to mention the fact that Ricochets send packets at well above
>> 50kbps, don't they?
>
>100kbps, but I have my serial port locked at 19.2...

But it is half duplex, so you are back to 50kps in real usage....


Robert Moskowitz
Chrysler Corporation
(810) 758-8212




Message-Id: <3.0b15.32.19960911131055.00b03008@pop3hub.is.chrysler.com>
Reply-To: rgm3@chrysler.com
X-Sender: rgm3@pop3hub.is.chrysler.com
X-Mailer: Windows Eudora Pro Version 3.0b15 (32)
Date: Wed, 11 Sep 1996 13:16:00 -0400
To: Germano Caronni <caronni@tik.ee.ethz.ch>, "Bill Sommerfeld"@TIS.COM
From: Robert Moskowitz <rgm3@chrysler.com>
Subject: Re: Status of IPSEC Key Management
Cc: ipsec@TIS.COM
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk

At 09:21 PM 9/10/96 +0200, Germano Caronni wrote:
>
>But then, if you are going to use ATM, you do not care very much about this
>issue. If you have low bandwith sparse traffic, the establishment of the VC
>will cost you much more than sending 2 or 3 or 10 cells. If you have high
>volume traffic, you do not care much about the +20 bytes per e.g. 4kB AAL5
>frame you are sending out.

But your DAVIDC (or whatever the name is) friends have reserved a PPP
protocol # for ATM over PPP so that ATM can go anywhere!  ;)


Robert Moskowitz
Chrysler Corporation
(810) 758-8212