[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...
> > 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.
> 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.
> 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.
> > 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?
> 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?
Scott
Follow-Ups:
References: