[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Bridging non-IP traffic over IPSec
From: Eric Bomarsi <ebomarsi@xedia.com>
Subject: Re: Bridging non-IP traffic over IPSec
Stephen Kent wrote:
> ESP requires the next protocol to be a transport protocol or IP, so
> carrying an Ethernet frame directky above ESP would not be valid.
What about.....
In RFC 1700 the IP protocol numbers include:
97 ETHERIP Ethernet-within-IP Encapsulation [RXH1]
Yes, that's another putative encapsulation.
It boils down to two basic choices:
1. Something that uses UDP, such as L2TP or PPTP
2. Something that is a Transport Protocol over IP, such as GRE and
ETHERIP. At least there's an informational RFC on GRE, which is more
than can be said about ETHERIP. (Is Russ Housley still at Xerox, and
is he willing to document what he did?)
The choice of exactly which protocol to use in each case is, to my
mind, just a distraction from the real issues. The real issue is what
the headers before these encapsulation headers look like.
We have reached a point where we believe it's OK to use ESP in
transport mode, so long as the security gateway fully decapsulates the
inner protocol. So that helps us on headers.
Also, let's note that either of these stacks can bridge or route.
With PPP on L2TP or PPTP, you use BCP to bridge. With GRE, you use
protocol number 0x6558 for Ethernet bridging. (You presumably use
some number Cisco hasn't published for 802 bridging for FDDI or
Token-Ring.)
Of course, if you were briding in GRE, you would have to expand the
header to 8 bytes and include the Sequence Number field, since
bridging is defined to require non-reordering of packets. (Another
nuisance of bridging.) Using the ESP anti-replay counter for
reordering protection would be an unacceptable layer violation.
References: