[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.
>
Yes, a security gateway does provide security services for networked
entites. As far as client negotiator is concerned, it is providing
security negotiation service to a client (which in this happens to
be a VPN node), not the clients supported by the client. I think, it
would be the job of VPN GW client to interface with the negotiator
such that its ID and its secure policies are communicated to the negotiator.
That way, the negotiator in turn can pass on the information in turn, as
part of SA negotiation between GW clients.
> > > > 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.
>
Thanks for the clarification. How does it allow TCP/UDP port info? Can you
point me to a section that describes this. Thanks.
> > 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).
>
Thanks for the clarification. I do think, it is a good idea to have a
seperate policy payload. Doing this in IPsecond sounds good.
> > 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.
>
The IKE document throughout refers IKE as a process. I dont believe this
process is required to be on the same node as VPN, right. If an enterprise
has multiple VPN nodes (for load balancing, or whatever), there could be
a single IKE negotiator process supporting all the VPN nodes. And, this
process can be residing on a stand-alone machine with significant hardware
and disk space capacity.
I think, we need a clarification on what an IKE client is. Here is what
I think IKE does and who its clients are. IKE is providing SA establishment,
maintenance and termination services to clients. The clients are SA
end-points. So, if a client happens to be a VPN GW node, and has multiple
other clients (i.e., end hosts) that it supports, the clients supported by
the VPN are NOT the clients of IKE. It is up to the VPN to notify its
policies to IKE. Does this make sense?
> > 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.
>
I think, Bryan is arguing for making ID payload (which in its current state
is the poor man's policy descriptor) mandatory.
> Dan.
>
>
cheers,
suresh
Follow-Ups:
References: