[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: comments on VPN framework document
Bernard, Stephen,
> >'IPSEC-tunnel' is that it is not a
> >tunnel at all, really - just a
> >security encapsulation scheme.
>
> By my definition, a tunnel exists whenever you
> encapsulate one packet within another packet.
> By that scheme an IPSEC/IP tunnel is as much a
> tunnel as an IPSEC/L2TP tunnel.
I agree. Whether you choose in an implementation
to model an IPSEC tunnel as a virtual interface
or as an encapsulation method on an existing
interface is an implementation issue, not a
standards issue. I think there are a lot of benefits
to modelling it as a virtual interface, as then
you can treat all forms of tunneling in a similar
manner. Also as 'policy' is something that you
probably want to apply on all interfaces, physical
or logical, you may also want, in an implementation,
to have a common method of applying policy across
all interfaces. The IPSEC documents kind of enmesh
policy and protocol issues, for the purpose of
describing the external functionality of a compliant
implementation, but that's just a descriptive
device.
There is, however, one protocol issue which I
believe unnecessarily complicates using an IPSEC
tunnel as a virtual interface, and which should be
addressed:
Take a basic networking task (nothing to do
with IPSEC) of configuring a point to point
link (e.g. an ATM PVC) between two routers.
When I configure the link I don't need to
know the set of layer 3 packets that will at a
later point travel over the link. Instead a
set of packets, determined by a dynamic routing
protocol, will be sent over the link, and this
may change over time. So the steps are
- configure the layer 2 link
- turn on routing over this link
- packets get sent on the link
Now the problem with using an IPSEC tunnel in
this way is that it is currently a requirement
that when an SA is established between two
routers (security gateways), it is necessary
to specify the set of IP packets that will
be sent over the SA - the proxy IDs (IDci and
IDcr) in a Quick Mode message must be non zero.
If you haven't, at this point, even turned on
routing to run over this IP tunnel link, then
you don't know what the set of packets will be.
A mode of operation that allowed these fields
to be unspecified would solve the problem. The
security policy to be applied on the SA (by
the receiver of the SA) could be determined
by the identify of the Phase 1 negotiator,
possibly in conjunction with extra information
(such as a VPN-ID) conveyed before the Phase
2 exchange. Essentially this is a policy issue.
The policy to be applied on a Phase 2 SA, should
not have to be signalled in the establishment of
the SA. We should allow the identification of
the policy to be applied to be based on information
other than the source and destination IP addresses
of the packets that will be sent over the SA. This
becomes particularly important if you are running a
network where there are multiple domains (e.g VPNs)
all using the same address space (e.g. 10.0.0.0/8).
Bryan
Follow-Ups: