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

Re: Bridging non-IP traffic over IPSec


Well, the additional GRE header is only 4 bytes, but I believe you
still need the additional and redundant IP header (20 bytes):
    IP/ESP  (ipsec header)
    IP/GRE  (gre header)

Furthermore, the issue of hitting the IP lookup table twice is
unfortunate, although probably minimal hit with caching.

Another issue is that the administrator has to configure the
GRE tunnel in addition to the IPSec tunnel policy. They
won't like that.

And finally, GRE is not standard, so at best we'll have a defacto
standard if this becomes practice.

I'm not familiar with IETF numbering policies, but if we could just
get a 1-byte identifier to specify "bridging", we've solved all these
problems. If not, then we pick a bridging identifier or make it user-
configurable and we have a defacto standard that's better than
GRE bridging and no less standard. But I think it would be much
nicer to do this the right way and get an official number.

As far as the client is concerned, the MTU and link speed
problems seem far worse on the dial-up link than on the backbone
between gateways or between the RAS and gateway. I am not
familiar with the IPX config, but there are a lot of PPP-like dialup
features going into IKE now. It just seems these issues can be
solved without putting L2TP on the client.

/Eric Bomarsi

John Shriver wrote:

> 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: