[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ipsec in tunnel mode and dynamic routing
Ricky Charlet wrote:
> Howdy,
>
> comment below...
>
>
>>Ricky Charlet wrote:
>> > One large point to keep in mind about that draft is that its intended
>> > purpose is to create overlay networks. The interested audience for
>> > this is comparatively small. It goes beyond the aims and purposed of
>> > creating secure VPN networks.
>>
>>Not necessarily. Using IPIP tunnels + ipsec transport mode is a full
>>replacement for IPsec tunnel mode, i.e. you're not loosing anything
>>by always using the former instead of the latter. Thus, you can use
>>our approach to "only" create secure VPNs, with don't need dynamic
>>routing.
>>
>>
>
> First off, I want to say that I respect the IPsec based overlay network
> stuff that you and Joe have done. I am not commenting negatively on that
> work. But I have never before considered it as a replacement for our
> current IPsec tunnel mode. I was not aware that this was part of your
> vision for IPIP encap + IPsecTransport.
>
> And I think you may be overreaching in that aim. Even if the
> IPIPencap+IPsecTransport preserved all the security properties of IPsec
> Tunnels (and I would need to be convinced of that),
Please phrase future discussions in the context of the draft's discussin
of these issues.
> It still introduces
> a large bit of management complexity. IPsec gateways would be
> responsible for encapsulating to and securing with a peer who was
> selected by a dynamic routing protocol rather than administratively
> configured. It seems on the face of it, that a VPN network which can
> have its peers altered by routing protocols is more open to DOS in
> particular and less trustable in general. It also requires
> administrators to configure security policy on all IPsec gateways which
> MIGHT be selected as peers - and that seems a burdensome task and
> difficult thing to keep current.
We're not advocating hop-by-hop IPsec per se. We need HBH IPsec for
overlay network deployment, esp. where the endpoints are not necessarily
IPsec-capable. Decoupling tunneling from IPsec has advantages any time
there are multiple keyed paths with dynamic selection of paths based on
routing decisions, which could be E2E as well.
> If you don't mind, I've grown quite comfortable with tunnel mode and
> would like to keep it for my VPNs if there is no pressing reason to
> change.
The fundamental issue is that you (generally, not personally) and
everyone else (multicast, mobile IP, etc.) have their own tunnel system,
and they're all integrated. We're proposing a modular approach, and have
already discussed (in the ID) both its advantages and security.
Tunnel mode, IMO, is a complication of IPsec, not a simplification. The
post-processing checks of iteratively forwarded packets (packets that
continue to be processed by the forwarding after decryption) are already
required by RFC2401 (i.e., tagging the packet and checking those tags).
RFC2401 tunnel mode determines the encryption key AND the outer unnel
header by the (pre-IPsec) IP packet header. The first step may be IPsec,
but the second is forwarding. Having IPsec replicate forwarding requires
sychronous management of the key database with the forwarding tables.
This too is described in detail in our ID.
Joe
References: