>Personally, I've *never* understood the emphasis >placed on "Transport mode"v.s. "Tunnel mode". The distinctions came from discussions on the interoperability of "end system" implementations and "intermediate system" implementations. It seems reasonable to require support of a "tunnel mode" in an end system to ensure interoperability of the two types of implementations. End system implementations (aka transport mode) are easily developed that do not support the tunnel mode. Paul -------------------------------------------------------------- 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: AH in tunnel mode
- From: "C. Harald Koch <chk@border.com>" <ipsec-request@neptune.hq.tis.com>
- Date: 20 Aug 96 12:38:19
- In-Reply-To: Your message of "Tue, 20 Aug 1996 14:43:42 -0400". <2.2.32.19960820184342.00ab80cc@mailserv-H.ftp.com>
- Organization: Border Network Technologies Inc.
- Phone: +1 416 368 7157
- References: <2.2.32.19960820184342.00ab80cc@mailserv-H.ftp.com>
- Sender: ipsec-approval@neptune.hq.tis.com
> I would like to know what people think about AH in tunnel mode. Ran > suggested that I post this to the list to evoke some discussion and then add > the following text either in the AH spec or write an informational document > on using IPSec to build VPN's. Is tunnelled AH prohibited anywhere? i.e.: IP[fw1,fw2] | AH | IP[src,dst] | ULP Since AH has a "next hop protocol" field, and a valid protocol is IP (protocol #4), this should work fine (It does in my code :-). Personally, I've *never* understood the emphasis placed on "Transport mode" v.s. "Tunnel mode". There already exists a separate IP in IP document; adding AH and/or ESP between the two IP headers was obvious to me. I understand that specific security issues arise with this configuration, but those should be listed, IMHO, as an implementation note, instead of separating out IP from every other possible "next hop" protocol in the standards. Maybe I'm just missing something obvious. If so, I beg enlightenment... -- C. Harald Koch | Border Network Technologies Inc. chk@border.com | Senior System Developer +1 416 368 7157 (voice) | 20 Toronto Street, Suite 400, Toronto ON M5C 2B8 +1 416 368 7789 (fax) | Madness takes its toll. Please have exact change.
-- END included message