[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: use of client IDs
Pyda Srisuresh wrote:
<trimmed...>
>
> I believe, Client ID is mandatory when IKE key negotiator and the
> client node for which it is negotiating are not the same.
I don't think this is true. That's not to say that it shouldn't be, but
I don't think that as things currently stand, it is right. See the
related post to see what the IKE doc says about this. Consider the
following scenario:
192.168.1.2 10.0.0.2
+----+ | 192.168.1.3 10.0.0.1 | +----+
| U1 +-| +-----+ +-----+ |--| U2 |
+----+ +===+ SG1 +===================+ SG2 +==+ +----+
| +---- + +-----+ |
SG2's SPD:
---------------------------------
192.168.1.0/12 (some SA spec)
(other SPD entries)
...
Now, SG1 negotiates a SA, and neglects to send a ID payload. SG2 selects
rule 1. Subsequently, SG1 encapsulates packets from 192.168.1.2, and SG2
uses the SA to decrypt/decapsulate the packets. Then, SG2 looks in its
SPD to ensure the resulting packet selectors match the SPD entry. Guess
what? They do...
> Given that the ID payload serves the dual role of providing
> identification as well as policy, this would become a requirement
> when the policy specification is expanded to include trasport level
> and other types of services.
The ID payload provides *identification*, not policy. Policy may be
selected based upon the provided identification, or perhaps based upon
some other criteria.
<trimmed...>
> I agree with what Bryan is saying here. But, SPD entries on a node cannot
> be allowed to be dictated by the peering external node. I would state that
> the responder would be expected to choose one of an existing matching SPD
> entries or a subset of a matching SPD entry to correspond to the new SA.
Yes, that's what I said, I think.
> Ideally, when the two parties have exact SPD entries (as far as traffic
> between the two parties are concerned) on either side, there is no problem.
> But, in the case where the SPDs do not match, the ID payload is supposed
> to automate the policy selection criteria.
>
I'm very confused by your terminology here. The parties may have an
exact match for the selectors in a SPD entry, and I think that's what
you mean here. However, whether they do or not, they will do the same
amount of work to look up a matching policy entry (using the packet
source IP or the ID payload content) either way, unless the ID payload
contains a FQDN or something, and they have to do additional protocol
backflips to get the info. Either way, the policy selection is
automated.
<trimmed...>
> When a secure gateway has multiple disjoint subnet or discrete hosts in
> the policy, you could setup multiple SAs to accomodate them. In the
> future, we need a way to clearly state the security policies; I.e., one
> that would allow you to specify discrete hosts, range of hosts, protocols,
> TCP/UDP ports etc. Otherwise, packets could get black-holed.
Yes, and it would also be nice to have a method for specifying 'all but
this one', i.e. a notch filter.
> Here is my thinking on this.
>
> An IKE negotiator is an entity by itself, independent of whether it
> is negotiating on behalf of a transport mode client (i.e., end host)
> or a tunnel mode client(say, VPN gateway). The IKE negotiator entity
> could be on the same node as the client for which it is negotiating
> or it could be on an entirely different node.
>
> So, it is important for the negotiator to identify the client for which
> it is negotiating, especially when the client is different node/address
> from that of the negotiator.
I never meant to imply that the negotiator should try to hide its
client, only to clarify the behavior when no ID payload is present,
which is well-defined.
> The ID payload semantics seems overloaded to carry both the client ID and
> the security policy applicable to client.
In the current design, the security policy is selected based upon the
identity of the client. This is based upon a typical identity-based
security policy model. If you want to use some other sort of model (e.g.
rule-based), then I suppose the identity isn't so important, and you
might need some other 'privilege-level' payload or something. I guess I
don't understand what you mean by 'overloaded' here, as it seems to me
to be serving one purpose: to identify.
> Well, there are many cases where an SPD selector could differ from an
> SAD selector.
Bingo - this is correct (and I missed it in my previous response), but I
don't think you fleshed it out properly below. It's when the SPD
selector is *not an address*, i.e. if it's a FQDN, or DN, or some
certificate field, then that selector (the one which matched the SPD
entry) won't be in subsequent packets, and hence cannot be used to
select the correct SAD entry.
Additional issues arise when the SPD selectors are address wildcards,
which also can't be used to select the SAD entry due to the possibility
of unintended collisions with earlier more precise SPD entries. One way
to clarify this distinction for purposes of discussion is to
differentiate between SPD selectors (which might be things other than
addresses, protocols, etc), and packet selectors (SAD selectors), which
are *always* addresses, protocols, and SPIs.
> If the selection criteria is set to be based on packet
> (as opposed to policy), every new packet matching the same policy but
> differing in one regard(say, IP address or TCP/UDP port) would require
> a new SA.
>
> In the case where selection criteria is set to be based on policy,
> the SA selection would match the selection of an SP. It is also
> possible for an SA to match multiple policies.
>
Again, your terminology confuses me. When you say 'the selection
criteria is set to be based on packet (as opposed to policy)', what do
you mean?
Follow-Ups:
References: