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

Re: Authentication using ESP in Transport Mode

Earlier, Ran wrote:
>>Gee, I hope not.  ESP directly inside ESP is bogus.   
>> 
>>Ran 

In article <9607170514.AA07071@maildig1.us.oracle.com> Paul wrote:
> 
>Hummm ... no, ESP inside ESP should be a fairly common case when two 
>workstations with ESP communicate through two encrypting firewalls using ESP.
> 
>I assume that you were thinking of ESP inside ESP with no intermedate 
>encrypting systems as a bogus example... 
> 
> 
>Paul 

Paul,

  I believe there was a communication gap, rather than a substantive technical
difference between what you mention and what I said.  Referring back to the
original set of notes below, please examine the area I've marked at the left
margin with "*" first to make clear what my comment quoted above was
referring to.

  It is bogus for a packet to be of the form: 
	[IP, s->d][ESP][ESP][ULP or IP]

  The case you mention (End-to-End encryption while traversing an encrypted
tunnel between two intermediate systems (e.g. routers or firewalls))
will have tunnel-mode ESP packets of the form:
	[IP, fw1->fw2][ESP][IP, s->d][ESP][ULP or IP]

where: 
  fw1,fw2 are addresses of the intermediate encryptors and the arrow separates
the source from the destination.
  s,d are the ultimate source and destination workstations that are also
ESP-capable.
  ULP == upper-layer protocol (e.g. TCP, UDP, ICMP)

Regards,

Ran
rja@cisco.com  

>--Boundary-22345810-0-0
>Content-Type: message/rfc822
>
>Date: 10 Jul 96 13:07:31
>From:"Ran Atkinson " <ipsec-approval@neptune.tis.com>
>To: ipsec@tis.com
>Subject: Re: Authentication using ESP in Transport Mode
>X-Orcl-Application: Newsgroups: cisco.external.ietf.ipsec
>X-Orcl-Application: In-Reply-To: <9607101438.AA00827@wellspring.us.dg.com>
>X-Orcl-Application: Organization: cisco Systems, Inc., Menlo Park, Ca.
>X-Orcl-Application: Sender: ipsec-approval@neptune.tis.com
>X-Orcl-Application: Precedence: bulk
>
>
>Someone wrote:
>>The packets would be:
>>
*   IPv4                           ...outer header as it travels the net
*     AH                           ...is this needed?
*       ESP                        ...for firewall/tunnel
*         ESP                      ...for remote to internal node
*           original TCP/UDP/etc.  ...real data.
>
>I don't think so.  I was thinking more like:
>
>	IP (source=outside firewall, dest=firewall)
>	ESP with combined transform
>	IP (source=outside firewall, dest=inner destination) 
>	AH alone OR ESP with combined transform
>	inner IP/TCP, IP/UDP, TCP, UDP, etc.
>	
>>Has anyone implemented this?
>
>My description above is implemented by the NRL source code if one configures a
>"secure IPv4 tunnel" for the outer path and also the user requests ESP
>tunnel-mode on the original packet.
>
>>Are we really really sure any existing implementations correctly allow ESP
>>inside ESP?
>
>Gee, I hope not.  ESP directly inside ESP is bogus.  
>
>Ran
>rja@inet.org
>
>
>
>--Boundary-22345810-0-0--
References: