Date: Thu, 25 Sep 2003 13:23:42 -0700 From: Joe Touch <touch@ISI.EDU> To: Russ Housley <housley@vigilsec.com> CC: yushunwa@ISI.EDU, larse@ISI.EDU Subject: Re: draft-touch-ipsec-vpn-05
Russ Housley wrote:
The IESG reviewed this document. A an issue regarding section 3.3 was raised. It says:
3.3 Solving Problem 2: Source Address Selection
Section 2.4 gave an overview of IP source address selection and its
dependence on interfaces and routes.
Using RFC 2003 IPIP tunnel devices for VN links, instead of IPsec
tunnel mode SAs, solves this issue directly. The IPIP tunnels are
full-fledged interfaces with associated routes, so that routes [N4]
and address selection as described in [N6] can operate as specified.
This doesn't seem to be an adequate treatment of the problem. In general, the host may still have to select among multiple possible source addresses; is this trying to say that by specifying a system in which the tunnels are interfaces the problem collapses from source selection to interface selection? If so, a more fully worked example of why this works for the examples given seems like it would be useful.
Sec 2.4 explains this issue, and showed how IPsec SAs fail in that regard. In that section we say:
According to [N6], the IP source address of an outbound packet should: (1) for directly connected networks derive from the corresponding interface, or (2) derive from existing dynamic or static route entries to the destination, or finally (3) derive from the interface attached to a default gateway.
As you observe, this means that by using tunnels as interfaces the problem collapses to interface selection. RFC1122 ([N6]) describes interface selection in detail. Not only does the problem collapse to a prior problem, the known (and widely implemented) solution provided in RFC1122 solves both.
We could revise the paragraph you quoted from Sec. 3.3 as follows to clarify this issue:
--
Using RFC 2003 IPIP tunnel devices for VN links, instead of IPsec
tunnel mode SAs, allows existing multihoming solutions to source address
selection ([N6]) to solve source address selection in this context as
well. As indicated in Sec. 2.4, according to [N6], the IP source address
of an outboubd packet is determined by the outbound interface, which is
in turn determined by existing forwarding mechanism. Because IPIP
tunnels are full-fledged interfaces with associated routes (as in Sec. 3.2 of [N4]), the routes and address selection as specified in
[N6] can also operate as desired in the context of VN links.
--
Also, there are at least two working groups that are doing work on VPNs: IPsec and L3VPN. Have you asked either of them to review this document?
Yes, as noted in the Acknowledgements:
The authors would also like to thank Jun-ichiro (itojun) Hagino and the KAME project for bringing IKE implications of this proposal to our attention, as well as implementing the mechanisms in this draft in the KAME IPv6/IPsec network stack. Members of several IETF WGs (especially IPsec: Stephen Kent, PPVPN: Eric Vyncke, Paul Knight, various members of MobileIP) provided valuable input on the details of IPsec processing in earlier revisions of this document.
(PPVPN having preceded L3VPN)
The earliest version of this work was presented to the IPsec WG in Spring 2000 in Adelaide. We have been in constant contact with that WG on this issue since that time. In Winter 2001 in Salt Lake City, the WG decided that this document should remain an individual Informational submission, and that it would be complemented by the pending revision of RFC2401.
The members of the IPsec WG have indeed reviewed this document as well, and their comments have been incorporated.
As to the L3VPN WG, the information has largely flowed the other way. There have been, during the revisions of this document, several drafts in L3VPN which either revisit or build upon our draft (some of which even cite this draft). This is a particular reason why we look forward to the timely publication of this ID as an RFC.
I.e., in summary:
- it has been brought to the attention of IPsec since Spring 2000, and most recently in Winter 2001 it was decided to leave it as an individual submission, with mods incorporated into the pending 2401bis.
- it has been brought to the attention of L3VPN, largely to demonstrate IPsec-compatible methods for doing IP VPNs.
Please let me know how you want to proceed.
We would appreciate proceeding with publication, with the above modification, as an Informational RFC.
Please let me know if we can provide any further information.
Joe