[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: draft-ietf-ipsec-son-of-ike-protocol-reqts-00.txt
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
Follow-Ups:
References: