[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: null encryption
It would be very useful to get an agreement on 'what the VPN problem is', I
agree.
I consider IPSEC as 'just security'. Transport-mode protection is clearly
not a
tunnel and tunnel-mode is poorly named - I think. 'Tunnel-mode' is more
like
'encapsulation-mode' - If you've encrypted the original header, some other
address
header needs to be applied. Originally, IPSEC negotiated just authentication
and encryption parameters and now covers compression as well - can be it be
expanded further?
As things stand, I think the only approach we have (our implementation) is
to use
L2TP with IPSEC protection (L2TP does the tunnel, IPSEC protects with
transport
mode). I know other folk have various IP-tunnel things that 'just work'
over IPSEC
- presumably in Transport mode.
I suspect the answer is a hybrid of L2TP (voluntary model) and the various
IP/IP tunnels.
As a pet interest, I'd like to see some time spent of 'VPN tunnel quality
monitoring'.
Steve.
-----Original Message-----
From: Bryan Gleeson [mailto:BGleeson@shastanets.com]
Sent: Tuesday, September 15, 1998 1:03 AM
To: Henry Spencer; Juha Heinanen
Cc: ipsec@tis.com
Subject: 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.