draft-ietf-ipsec-son-of-ike-protocol-reqts-00.txt
Shane Amante <shane@amante.org> Fri, 21 December 2001 08:18 UTC
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fBL8IK227927; Fri, 21 Dec 2001 00:18:20 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA21894 Fri, 21 Dec 2001 02:25:46 -0500 (EST)
Date: Fri, 21 Dec 2001 00:27:01 -0700
From: Shane Amante <shane@amante.org>
To: ipsec@lists.tislabs.com
Subject: draft-ietf-ipsec-son-of-ike-protocol-reqts-00.txt
Message-ID: <20011221002701.G1426@nike.amante.org>
Mail-Followup-To: ipsec@lists.tislabs.com
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
The following comments and suggestions relate to requirements offered in: draft-ietf-ipsec-son-of-ike-protocol-reqts-00.txt. 7. Improve Simplicity [NOTE: this is kind of touched upon in Section 6 "Documenting Errors", but I think the following point needs to be called out in specific detail in Section 7.] There MUST be clear, concise definition of errors reported to end-users during or after a failed IKE negotiation. I recommend something along of the lines of SMTP or HTTP status codes be tailored specifically to the IKE state machine and its transactions. Furthermore, an end-user should NOT have to enable IKE debugging on a IPSec device in order to expose the specific reason (IKE status code) why an IKE negotiation failed. The goal here is to _consistently_ deliver clear, concise messages to the "common [wo]man" to make it easy to spot, relay and/or troubleshoot error messages. A.1 + A.2: "Policy". I think this really needs to be expanded upon, and clear requirements set forth. Although RFC2401 section 4.4.1 (SPD) refers to 3 choices wrt to "Policy", there really are four choices: - packet matches, encrypt - packet matches, bypass (don't encrypt) - packet doesn't match, drop - packet doesn't match, bypass (only in OUTBOUND case) The last case applies to either the telecommuter (site-to-site tunnel) or the mobile remote-access (RAS) client scenarios. In those cases, there are two choices for the site security administrator to make: 1) Allow the "client" to only be single-homed, thus ALL traffic needs to traverse the IPSec tunnel to the "hub" location. In the case of traffic legitimately destined for the Internet, this could add significant latency and might raise other security policy concerns. 2) Allow the "client" to be dual-homed. Encrypted traffic goes to the "hub"; Internet traffic bypasses the tunnel and goes immediately to the Internet. There are legitimate reasons for organizations to implement either #1 or #2. Thus, in order to retain flexibility IKE SHOULD have the ability to push/pull a policy to the client. (Ideally, this push/pull of a full policy could be avoided by exchanging a HASH of the whole SPD or a HASH for each rule that makes up the SPD -- obviously, only if it doesn't match does a transfer of the policy elements begin). Appendix A, General Comment: Another piece missing from each of the scenarios proposed is: IPSec's relationship with firewalls and/or midcom-devices. In particular, how is an IPSec gateway, at say a headquarters/hub location, deployed in relationship to a firewall (assuming the firewall and IPSec gateway are not co-located on the same physical device)? Three answers: a) On the public-side of the firewall, (e.g.: serially, sharing the same forwarding path); b) Beside the firewall, (e.g.: in parallel, creating separate forwarding paths as well as two, separate entry-points into the same 'internal' LAN); c) On the private-side of the firewall. Could either be serially, as in case (a), or off on a DMZ port of the firewall. All raise interesting security issues not only for protecting the IPSec gateway from the outside world, but also for protecting the internal LAN from traffic emerging from an IPSec tunnel. (Some may argue that the "SPD" on the IPSec gateway is good enough to protect the internal LAN, but I say to them: "no, it's not" if you believe in 'defense-in-depth'). To further complicate things, in case (c) what happens if the IPSec/IKE gateway is assigned an RFC1918 address on the internal LAN and the firewall is performing static NAT translation? Is this a supported configuration? Or, should it be the case that this is a gross hack and, therefore, will not be supported? Ideally, all this should be documented in a BCP, but consideration of firewalls needs to be accounted for now just as are NAT's. A.1 VPN Site-to-Site Tunnels "Operational Characteristics": I recommend updating the first sentence to the following: VPN Site-to-Site Tunnels may be between two, or more, devices ... ^^^^^^ ^^^^^^^ I agree that one tunnel will only exist between two SG's, but if you're talking about multiple tunnels you can create more complex toplogies. Finally, one last requirement: IKE/IPSec gateways SHOULD support "hot-standby" fail-over. No, this is NOT an end-user application problem, particularly if IPSec is to be considered a serious contender in the VPN space where SLAs are all about uptime. As an example of how serious uptime is to operators take a look at the Routing Area. Within the last year, IS-IS, OSPF + BGP all have proposals to keep the forwarding plane operational even if the control plane goes awry: http://www.ietf.org/internet-drafts/draft-ietf-isis-restart-00.txt http://www.ietf.org/internet-drafts/draft-ietf-ospf-hitless-restart-01.txt http://www.ietf.org/internet-drafts/draft-ietf-idr-restart-01.txt If hot-standby fail-over isn't considered as part of the first round of IKEv2, then at least consider what extensibility will be required to allow this in the future witout much pain. -shane
- draft-ietf-ipsec-son-of-ike-protocol-reqts-00.txt Shane Amante
- Re: draft-ietf-ipsec-son-of-ike-protocol-reqts-00… Jan Vilhuber
- RE: draft-ietf-ipsec-son-of-ike-protocol-reqts-00… sankar ramamoorthi
- Re: draft-ietf-ipsec-son-of-ike-protocol-reqts-00… Shane Amante
- Re: draft-ietf-ipsec-son-of-ike-protocol-reqts-00… Paul Hoffman / VPNC