Ran,
>Paul,
>
> I believe there was a communication gap,
>....
There was no communication gap, I was disagreeing with your statement:
> It is bogus for a packet to be of the form:
> [IP, s->d][ESP][ESP][ULP or IP]
There was a head space gap. Thanks for leaving me a possible out... but I'm
wrong. ESP over ESP is not totally bogus, but the example of two hosts going
through two firewalls is most easily handled by:
[IP, fw1->fw2][ESP][IP, s->d][ESP][ULP] ... as you pointed out.
You can get tricky at firewalls and could get rid of the inner IP. This has
not been discussed much on the IPsec list and requires red-side reassembly of
packet fragments. This also requires the use of the inner SPI to map incoming
packets to a source / destination address pair. This would need to be a
Firewall "enhancement" that would require special negotiations or SPI
conventions to establish.
So, it is much easier to just use the ESP-IP-ESP sandwich for the dual
firewall example. ESP over ESP still should be allowed... we should not limit
the creative use of multiple layers of security encapsulation.
Regards,
Paul
PS - also thanks Steve K. for keeping me honest on this :-)
--------------------------------------------------------------
Paul Lambert Director of Security Products
Oracle Corporation Phone: (415) 506-0370
500 Oracle Parkway, Box 659410 Fax: (415) 413-2963
Redwood Shores, CA 94065 palamber@us.oracle.com
!!! Still hiring, send resumes to: palamber@us.oracle.com !!!
--------------------------------------------------------------
-- BEGIN included message
- To: ipsec@tis.com
- Subject: Re: Authentication using ESP in Transport Mode
- From: "Ran Atkinson " <ipsec-approval@neptune.tis.com>
- Date: 17 Jul 96 08:47:55
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--
-- END included message