[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

draft-ietf-ipsec-son-of-ike-protocol-reqts-00.txt

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
Follow-Ups: