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

Re: issues with IKE that need resolution

> 
> Pyda Srisuresh wrote:
> > Dan Harkins wrote:
> > >
> > >   Is there a point in identifying yourself as "198.31.2.0/24"? What
> > > does that mean? "I speak for this network"? Without something like the KX
> > > record in DNS to delegate that authority why should I belive it? Chances
> > > are he'd probably be making this statement through another interface anyway
> > > so what should I do if 198.31.1.18 says "I'm 198.31.2.0/24"? Also, what are
> > > you going to do about the ID_KEY_ID identity? A certificate that certifies
> > > that my identity is an intentionally incomprehensible blob is not going
> > > to be all that useful.
> > >
> > 
> > I agree. I dont see much point in having IDs for address ranges and
> > transport IDs and so forth. Single address (or multiple addresses for
> > a multi-homed node) based IDs seem to be the only valid IDs (be it for
> > phase I or phase II).
> 
> Disagree. Ranges of addresses (etc.) are extremely useful identifiers
> for a security gateway which is representing those within the range. 
> 

Well, let me explain what I have in mind.

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?

> As for Dan's question,
> 
> > >   Is there a point in identifying yourself as "198.31.2.0/24"? What
> > > does that mean? "I speak for this network"? Without something like 
> 
> 
> Yes, "I speak for this network" is *exactly* what it means, and you
> don't need a kx record or anything like it to verify my veracity.
> Instead, you need a way to indicate in your policy entry that I am an
> authorized proxy in this case. I guess you *could* use a kx record if
> you want to, but that's an implementation detail.
> 
> 
> <trimmed...>
> 
> Dan wrote:
> > >   It seems to me that we have identities that are only useful in phase 1 and
> > > some of those should have ways to be encoded into a cert. There are others
> > > that really only make sense in phase 2 because their purpose is to
> > > constrain use of an IPSec SA. As an example, a gateway product receiving
> > > phase 2 identities of IDci = "IPv4_ADDR 132.39.3.12" and IDcr =
> > > "ID_FQDN dharkins@cisco.com" would not be particularly useful. What
> > > does "dharkins@cisco.com" mean? There is no machine cisco.com and there
> > > sure isn't a user dharkins there. Clearly, FQDN is a phase 1 identity and
> > > a way to encode it in a cert is good. But passing it in phase 2 would not
> > > make much sense. Similarly, a list of subnets is not a very good phase 1
> > > identity and I don't see much value in defining a way to encode that in a
> > > cert but as a phase 2 identity it may be quite useful. Or am I missing
> > > something here?
> > >
> > 
> > I agree, ID payload is predominantly useful in phase 1. However, there
> > is need for ID payload in phase II as well. When the IP address of client
> > for which IKE is negotiating is different from that of IKE itself, it is
> > necessary for IKE to identify the client ID in phase II, (just as it
> > specifies the ID for itself in phase I).
> > 
> > What we need is a new type of policy payload in phase II.
> 
> 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?

> > >From the IKE stand point, I believe, we need to be able to do the following:
> > 
> >      (1)  Identify one or more policies associated with an SA.
> >           Each Policy needs to be assigned an ID, to identify with
> >           during the lifetime of SA (or, its extended lifetime). Policy
> >           could be as simple as:
> > 
> >           PERMIT <src address list> <dest address list> <IP protocol>
> >                  [<src transport ID list>] [<Dest transport ID list>]
> >                  [<Additional options?>]
> > 
> >           If there is rough consensus on this approach, I dont see a problem
> >           with coming up with a payload format to represent policies.
> > 
> 
> I strongly disagree with your assertion, if I understand it correctly.
> Individual policies are a local matter and should NEVER be sent across
> the link, but should be somehow indexable based on conversational
> context. We currently use either the ID payload or the IP header
> contents to index these. We may also use certificates, FQDNs, and
> whatever else is defined in for the ID payload, and this whole
> (sub)thread started as a result of the assertion that we need other
> indices.
> 

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

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

> >      (2)  Ability to add/delete policies dynamically to an SA.
> > 
> >           This would be particularly useful when some applications
> >           require policy changes on the fly. Ex: Take a policy that requires
> >           encryption on H.323 application sessions. The signalling protocol
> >           in H.323 sets up sessions dynamically and these dynamic sessions
> >           need to be notified so that all such sessions are supported by
> >           IPsec.
> > 
> 
> Again, I'm not sure I understand what you mean here, but will point out
> that it is possible to share an existing SA, and [ARCH] gives the
> details. However, difficulties arise if you negotiate the SA for 2
> specific endpoints using IKE, then want to try to piggyback others
> (whose selectors will not match upon decryption) onto the session if
> both sides do not strictly comply with description in [ARCH]. Again,
> though, these are local implementation issues, I think.
> 
> Scott
> 

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.

cheers,
suresh
Follow-Ups: References: