Re: draft-ietf-ipsec-son-of-ike-protocol-reqts-00.txt
Jan Vilhuber <vilhuber@cisco.com> Fri, 21 December 2001 22:43 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 fBLMhJ229796; Fri, 21 Dec 2001 14:43:19 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA24012 Fri, 21 Dec 2001 17:05:34 -0500 (EST)
Date: Fri, 21 Dec 2001 14:15:02 -0800
From: Jan Vilhuber <vilhuber@cisco.com>
To: Shane Amante <shane@amante.org>
cc: ipsec@lists.tislabs.com
Subject: Re: draft-ietf-ipsec-son-of-ike-protocol-reqts-00.txt
In-Reply-To: <20011221002701.G1426@nike.amante.org>
Message-ID: <Pine.LNX.4.21.0112211411220.3044-100000@janpc-home.cisco.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
On Fri, 21 Dec 2001, Shane Amante wrote: > 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. > Surely you don't think that belongs on a protocol spec. However you choose to implement this is up to you. I certainly don't object to clarifying error codes, but a protocol spec doesn't need to spell out how these should be displayed to the user. jan > > 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 > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847
- 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