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

Re: use of client IDs

  Bryan,

On Thu, 18 Jun 1998 19:50:12 PDT you wrote
> 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".

What does a security gateway do? If it provides security services on
behalf of other networked entites then I think the draft is decidedly
unambiguous. When some box is operating as a security gateway-- when "[it]
is acting as a client negotiator on behalf of another party"-- it must
use client IDs in the phase 2 exchange to identify the traffic to be
protected. This is, of course, based upon my view of what a security
gateway is. If your view is different please tell me how.

> > > 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. 

It already allows TCP/UDP port info and subnets and ranges. No, it can't 
express multiple disjoint subnets as a single entity. You need as many SAs 
as you have subnets in that case. This limitation (and also the inability
to express the "everything except..." construct) is acknowledged.

>                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.

This is an "IPSecond" issue and a draft on how to do this is needed (hint).

> 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.

What is it doing then? Note that that client can be an entire class-B network 
if you like; client != host.

> 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. 

Bad example. MPLS switching is not done "on behalf" of hosts any more than 
routing protocols are. If we were talking about link encryption it might
be more accurate, but who is your peer? You want a single SA to protect 
multiple disjoint networks. This SA has a single destination address. In 
the absense of security do all packets from these multiple disjoint networks 
get routed to this destination? I doubt it. But if they do then send all 
that traffic through a GRE tunnel and protect it with IPSec. 

  Dan.
Follow-Ups: References: