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

Re: Bridging non-IP traffic over IPSec




For site-to-site LAN bridging over IPSec, the GRE solution
seems unnecessarily complex:

1) The redundant headers:
    IP/ESP/IP/GRE/<eth-frame>
2) The additional administrator config to set up the GRE tunnel.
3) The 2nd redundant pass through the IP forwarder.

Instead, why not simply use the "Ethernet-Transparent-Bridging"
protocol identifier used in the GRE header in the ESP protocol
field and eliminate the GRE tunnel:
    IP/ESP/<eth-frame>

This is far simpler for me to stack in my gateway, more efficient,
and eliminates administrator config. Am I missing something?

/Eric Bomarsi

"Scott G. Kelly" wrote:

> John Shriver wrote:
> >
> > Well, GRE is an Informational RFC, so GRE is not likely to be part of
> > an IETF Proposed Standard solution.  But, if you do it, you sure will
> > be interoperable with Cisco...
> >
> > Certainly, it will work, and you can express GRE in the SPD.  But, the
> > SPD (and IKE negotiation) can't really negotiate what goes over the
> > GRE.  Is IP allowed over it?  IPX?  Transparent bridging?
> >
>
> This is a timely topic, I guess. I would say that what goes over GRE is
> a local policy issue, and probably not an ipsec issue per se. That is,
> it would be up to your GRE subsystem to determine what it is willing to
> encapsulate, and then up to you ipsec subsystem to determine if policy
> permits GRE to pass. On the other hand, I guess looking into a GRE
> packet to see what protocol is being encapsulated is not really that
> much different than looking into a tcp/udp packet to see what ports are
> involved, so maybe it's not such a far-fetched idea, at that.
>
> > One thing that is standards track, and people have been implementing,
> > is L2TP.  Put PPP over that, and then you have a place to run non-IP
> > traffic.
> >
> > Again, the SPD can't really control what goes over.  But, you can
> > express the L2TP UDP port in the SPD.
> >
> > As above, you will be interoperable with Cisco.
> >
>
> I guess the main problem I have with using l2tp in this case has to do
> with efficiency. Unless l2tp has radically changed in the last 2 years,
> I think it really is overkill for this particular use. Perhaps it's time
> to dust off the GRE RFC and rev it...



Follow-Ups: References: