[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: use of client IDs
Scott, Pyda
> 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.
I think the current draft is sufficiently ambiguous that it does not
rule out either conclusion. There is definitely a need for a statement
that "for a security gateway the use of the client ID is foobar", where
foobar is either "mandatory" or "optional".
> > 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.
With the concept of client/proxy negotiation I think the ID payload
is overloaded with the concept of policy. If this field is extended to
include multiple subnets, and TCP/UDP port info and whatever, I think
it becomes clearer that it is overloaded, as then there would be a need
to talk about an IKE negotiation on behalf of a client flow, or on
behalf
of a flow aggregate which included many clients, for example. Right now
I view it as being a poor man's policy descriptor - which is capable
of only representing a limited set of policies, and cannot deal with
the case of a router that is serving multiple disjoint subnets. I don't
think that the capability of including policy info in an IKE exchange is
a bad idea, but I think overloading the ID payload with policy semantics
is a bad idea. Instead I think a separate policy (or selector) payload
should be added, and that the ID payload should be left to identify the
thing that is initiating or terminating the SA.
The model that a security gateway is always "negotiating on behalf
of" a client may be intuitive in some scenarios, but I believe is not
in others, and that this model should not drive mandatory protocol
behaviours.
For example if there are two hosts communicating over the
Internet, and somewhere in the middle two routers, over which the host
to host traffic travels, decide to set up an MPLS label switched path
between themselves to provide for some traffic engineering, I wouldn't
view the setting up of the label switched path as being "on behalf of
the client that was ultimately sourcing the IP packets". It is rather
a policy decision made by the domain administrator, and is completely
transparent to any hosts, who probably have no idea of what
an MPLS label switched path was or why they would ever want someone
to get one on their behalf. Also you wouldn't want to force a separate
label switched path for every client or client address range (subnet)
since that may be irrelevant to the policy aims of the administrator.
I think exactly the same situation arises with setting up an IPSEC
tunnel between two routers / gateways. In both cases there is a
"connection" (label switched path or SA) and there is a
filtering / selector policy which determines which packets get what
label or get transmitted on what SA. Now if the client ID were
mandatory for a security gateway, then a separate SA *would* be required
for disjoint subnets, because the ID payload, in its duty as a poor
man's policy descriptor, was not capable of representing this and
this would be true even when the source addresses of the packets
to be sent on an SA are irrelevant to the policy that an administrator
wishes to implement.
Bryan Gleeson
Shasta Networks.
Follow-Ups: