Re: doi-07/interoperability questions
Yan-Fa LI <yanfali@hpcc103.corp.hp.com> Wed, 11 March 1998 00:32 UTC
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA13837 for ipsec-outgoing; Tue, 10 Mar 1998 19:32:58 -0500 (EST)
Message-Id: <9803110045.AA14142@hpcc103.corp.hp.com>
To: ipsec@tis.com
Subject: Re: doi-07/interoperability questions
In-Reply-To: Your message of Tue, 10 Mar 1998 17:06:51 -0500. <3505B97B.E28DAEF4@zk3.dec.com>
Date: Tue, 10 Mar 1998 16:45:49 -0800
From: Yan-Fa LI <yanfali@hpcc103.corp.hp.com>
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
If this assertion is correct, as a customer not a developer, I see a use for option 4 and would ask you not to remove it. Crypto arguments aside, there are three uses for this within the organization I work for. One, is the obvious situation where I have no other option, because of regulatory reasons, but I want improved IP where privacy is less important than integrity. For example, managing someone elses network across a less trusted network, note this managed network could even have non-publically routable address space. This would be end-to-edge. Two, improving leased line security from business partners, in an end-to-edge situation. Privacy is outweighed by authentication and integrity requirements with less client and gateway processing. This would be aided and abetted by simple firewall processing at the end of the tunnel on the edge hardware. Three, some xDSL providers are offering backhaul connections to corporate networks. Supposedly the traffic is across ATM VCs and so is as private as leased lines are today, questionable security premise I know. If we decided that privacy were not an issue, then it would fall back to authentication and authorization issues. AH, in tunnel mode, would suffice for this purpose, without the overhead for encryption; would this be worse or better from a client standpoint than ESP 56bit w/ HMAC and replay with SHA-1 ? I'd love to hear more expert opinion about this issue. Yes this is all end-to-edge centric. I'm thinking clients to gateways not gateway to gateway as yet. That's phase II ;) my $0.02 Y > Sounds to me you are suggesting the following changes to the arch spec > in section 4.5 Case 1. > ] > ] Transport Tunnel > ] ----------------- --------------------- > ] 1. [IP1][AH][upper] 4. [IP2][AH][IP1][upper] > ] 2. [IP1][ESP][upper] 5. [IP2][ESP][IP1][upper] > ] 3. [IP1][AH][ESP][upper] > ] > > Transport Tunnel > ----------------- --------------------- > 1. [IP1][AH][upper] (remove)4. [IP2][AH][IP1][upper] > (remove)2. [IP1][ESP][upper] 5. [IP2][ESP][IP1][upper] > 3. [IP1][AH][ESP][upper] (add)6. [IP2][AH][ESP][IP1][upper] > > Is this correct? > > I think it is ok to remove 4, it really doesn't buy you much. > I think we should keep 2. This new one for tunnel mode seem > to make sense. Now, should we restrict 6 to just gateway-to- > gateway? > > /eric
- doi-07/interoperability questions Ben Rogers
- Re: doi-07/interoperability questions Robert Moskowitz
- Re: doi-07/interoperability questions Ben Rogers
- Re: doi-07/interoperability questions Derrell D. Piper
- Re: doi-07/interoperability questions Ben Rogers
- Re: doi-07/interoperability questions Robert Moskowitz
- Re: doi-07/interoperability questions Eric L. Wong
- Re: doi-07/interoperability questions Ben Rogers
- Re: doi-07/interoperability questions C. Harald Koch
- Re: doi-07/interoperability questions Yan-Fa LI
- RE: doi-07/interoperability questions CJ Gibson
- Re: doi-07/interoperability questions Eric L. Wong
- Re: doi-07/interoperability questions Stephen Kent