[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: null encryption
Henry,
> > i don't know if the authors of the null encryption i-d have
> thought so,
> > but ipsec can be used as a generic tunneling mechanism
> alternative to
> > l2tp and in that application neither strong autentication
> nor encryption
> > is always be desirable.
>
> RFC 2003 defined a generic tunnelling mechanism two years
> ago; there is no
> need to misapply IPSEC for this.
As used with VPNs, there are a lot of requirements for a
generic tunneling protocol, over and above the need to
encapsulate data packets. For example to reduce the
configuration burden of setting up lots of tunnels, a
signalling protocol that allows the establishment and
negotiation of tunnel attributes is very useful. IPSEC
(IKE) and L2TP have such a signalling protocol. GRE
and IP/IP (RFC2003) do not. Also a multiplexing field
that allows multiple tunnels to be set up between the same
two endpoints is very useful (to support different VPNs
for example). Again IPSEC (via the SPI field) and L2TP
(via the tunnel-id, call-id fields) have such a
multiplexing field, but GRE and IP/IP do not. The ability
to send opaque and multiprotocol frames across an
IP backbone is also not addressed by IP/IP.
It is somewhat difficult to discuss particular modifications
and mechanisms in isolation (such as why a null encryption
and null authentication mode for IPSEC may be useful) without a
broader framework which indicates the problems that need
to be solved, and looks at the trade-offs involved in
adapting different existing protocols (such as IPSEC, L2TP,
MPLS, GRE and IP/IP) to solve these problems. To this end
we are currently working on a VPN Framework Draft, which
will be ready shortly, at which time I'll send notification
to the list for those interested.
Bryan Gleeson
Shasta Networks.