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

Re: issues with IKE that need resolution




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

Even then, it is interesting to note that some of the IDs (such as 
user name) are relevant only for IKE acting as a responder. ID types 
that may be used to initiate IKE session are only those for which there 
exists a way to match the ID to IP address (such as using DNS for 
FQDN ID and Certs to map a DN to IP address)

It would be nice to have this documented.

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

>   Addressing Scott's point: the ID payload is woefully overloaded. We're
> trying to express SPD policy in it and that was not its original purpose. 
> If I remember correctly Steve Kent removed some selector types from the
> Architecture Draft because IKE was unable to express them. It would not
> only be nice to have lists of address ranges, it would be nice to express
> the "everything but" construct: "this SA is to be used for all TCP except
> port 80". But I'm not sure the poor ID payload is the place to do it.
> 
>   Anybody have any ideas on how to express policy _right_? At the TrustMgt
> BOF in Chicago KeyNote was presented and that seems like a good start. 
> Actions are described as attribute-value pairs. IKE expresses attribute-value
> pairs quite well. If we had a good way to define desired actions ("I'd
> like to access your ftp server on machine A and your http server on machine 
> B and C") we could apply a request for those actions-- a series of 
> attribute-value pairs in some new payload-- to the collection of assertions 
> we have that define our local policy ("only <some class of people> may
> access our ftp server and all other TCP ports except telnet can be accessed 
> by anyone except <some other class of people> and RIP goes in the clear").
> 
>   I think the whole phase 2 identity stuff needs some serious revisiting
> and alot more than just defining new types. 
> 
>   Dan.
> 
Once again, I generally agree with what is said here. I was at the Trust 
Mgmt BOF.  But, I didnt come away with any definitive feeling of how the 
BOF was going to proceed and what the general aproach was going to be. 
>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.

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

<... snip>

cheers,
suresh


Follow-Ups: References: