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

Re: Bridging non-IP traffic over IPSec



The problem with any tunneling based on the "next header" field in the
ESP header (trailer, really) is that it is one byte, and it is from
the same very scarce space that IP Protocol Numbers come from.

They've already handed out some values of the IP Protocol Numbers for
tunneling protocols that have since become utterly obsolete: in
particular XNS.  I don't think that the IANA will start handing out
any new values anytime soon!

GRE does already have a value of the IP Protocol Number byte.  The GRE
header can be made very small.  Maybe IPsecond wants to move GRE onto
the standards track, if Cisco is willing to cede revision control.
(That would have the IANA assigning the 2-byte protocol ID's, which
are the same ones they use in their original proprietary pre-PPP
serial line format.)

As for MTU issues, at least in a Windows client the NDIS interface
allows the interface to present a reduced MTU, so even with all the
headers (GRE or L2TP or PPTP), fragmentation can be avoided.

But, on a tunnel between security gateways, fragmentation is a very
real problem.  IPX, for example, doesn't allow small-MTU networks to
connect ones with larger MTU.  One needs efficient IP reassembly, you
may have lots of fragments in mid-reassembly.

Another point, if you're using a tunneling protocol (GRE, L2TP, or
PPTP) inside ESP, you don't need to run ESP in tunnel mode.  You can
run it in transport mode with no loss of functionality.  Any of these
tunnels will require a private SA bundle, so that's not a problem
either.

But, the people who strongly wanted the Security Policy Database may
want to define new IPsec DOI Identification Types that would express
(at a minimum) other network layer protocols.  It could go all the way
to IPX network ranges, and things like that, if desired.  (But, this
is very IPsecond by now.)

One other advantage of L2TP that mustn't be ignored, having to use PPP
helps a lot in configuring IPX, etc.  Sure, we can add all that to
IKE, but that's a lot of new protocol design...


Follow-Ups: References: