[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: issues with IKE that need resolution
>
> [recipient list pruned...]
>
> Pyda Srisuresh wrote:
> <trimmed...>
> >
> > IKE is supposed to help negotiate keys and establish SA bundle between
> > IPsec peers. And, an SA bundle may be identified by the tuple of
> > (<security GW dest. address>, <Security protocols>, <SPIs>, <Symmetric keys>).
> >
> > With that in mind, I am not sure how identifying the subnets or address
> > list a VPN security gateway supports would help with IPsec processing,
> > except in the context of policy verification.
> >
> > If you agree with the above reasoning, I would say that IDs for subnets
> > is not required so long as there exists a policy payload. Does this make
> > sense?
> >
>
> I guess I'm not sure I agree with the above reasoning, although I don't
> necessarily disagree with the conclusion, depending upon what the
> 'policy' payload contains. In terms of your reasoning, have you
> considered that we may use IKE to establish *multiple* SA bundles
> between hosts/gateways, and that the individual SAs might have differing
> security requirements, and that a sorting mechanism for such individual
> connections vs security requirements may be realized using ports,
> protocols, addresses, etc? Also, consider asymmetric security
> requirements...
>
Yes to all your questions.
As for asymetric security requirements, is there something
specific you have in mind?
> > > I agree that we may need different payloads for the 2 phases, but think
> > > we need to reconcile the issue I raised in a related post, i.e. that the
> > > ID payload is, by definition, DOI-specific, and this (I think) means
> > > it's a phase 2 critter only. In that case, the new payload type would
> > > need to be in phase 1, or the appropriate language in the ISAKMP doc
> > > would need correcting.
> > >
> >
> > I agree, ID payload is DOI specific.
> > I also believe, the new policy payload is relevant to phase II only.
> >
> > Why do you say the new policy payload needs to be in phase I?
> >
> Didn't say that, only said that by the current language, the ID payload
> belongs in phase 2 only, so maybe we need a payload with a different
> name in phase 1. After sending that off, I came to believe that it makes
> more sense to change the language in the doc, and add a new payload (as
> you suggest) to phase 2.
>
The ID payload in phase 1 is DOI specific (ie, DOI as specified in SA
payload). Refer sec 3.8 in ISAKMP ver 10 draft for ID payload usage.
I dont see a problem with the ID payload remaining unchanged for
phase I and phase II.
> > A policy that asserts what datagrams are allowed to be processed over
> > an SA are not a local matter. Such a policy must be shared between
> > the SA peers.
>
> The minimum/maximum acceptable levels of security I am willing to apply
> for the datagrams I send to you is a local policy matter (mine). The
> minimum/maximum levels of security you are willing to accept for the
> datagrams I send to you is also a local policy matter with respect to
> you. That's why we negotiate, to find the middle ground.
>
OK.
> > Otherwise, what is stopping one end to use an SA to send
> > any datgrams it chooses to forward to its peer, while the peer doesnt
> > approve of these packets and simply drops or refuses to forward.
>
> The fact that the originator of the packets correctly identified their
> source(s) in the ID payload precludes the possibility that they would be
> inappropriately (and unknown to the originator) dropped at the
> destination peer. The SA would not have been established had their
> source(s) not been acceptable to the target gw. In that case, if the
> originator sends inappropriate packets, they will be dropped, and
> rightly so.
>
Well, it is simply that the source identification alone is not sufficient.
You need to verify aginst policies that include both source and destination
parameters.
> > > I still don't understand this resistance to using some sort of endpoint
> > > identifier to index policy - after all, we are using an identity-based
> > > security model, right?
> > >
> >
> > See my comments earlier. Idenitities, in my mind, are relevant only to
> > the extent of identifying IKE peers and Tunnel/transport IPSec end-nodes.
>
> Identities are of central importance to an identity-based policy model.
> It dawns on me that you may be thinking of some mechanism in which the
> gateways agree on some sort of policy which is independent of
> identities, and then any packet which comes down the SA is presumed to
> be of acceptable origin, and not subjected to any further validation
> (beyond decryption/authentication). Is this correct?
>
Yes, I do see policies and IDs as serving 2 different purposes.
yet, the second half of your assumption is not correct.
A packet that comes down an SA is verified against the policies
the SA is allowed to accept.
> > My point is simply that the negotiating peers must know the policy they
> > agree on for an SA. As for policy negoitiation in QM, IKE could pursue an
> > approach similar to what it does for SA negotiation.
> >
> > For example, the initiator could identify the policy it intends to pursue
> > for an SA and the responder would identify a subset of the orginal policy
> > it is agreeable to and responds with that policy. There, you have a common
> > agreeable policy between IPsec peers. Hope this helps.
> >
>
> Okay, but how do you represent the policy? How do you select variable
> levels of security, and based upon what?
>
I did make a straw-man proposal a couple of days of back for policy
representation.
As for how you associate different level of security (i.e., SA bundle
parameters) to different policies is a local policy matter on either
end. Only a common ground between both ends will end up being agreed
upon for SA and Policy.
> Scott
>
cheers,
suresh
References: