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

Re: use of client IDs



> 
> 
> correcting my previous post ...
>  
> > ... Thus the semantics of an absent client ID are "anyone 
> > behind this trusted gateway", not "anyone". 
> 
> Dan pointed out that this is completely wrong. What I meant 
> to say was "the semantics of an absent client ID *should be*
> anyone behind this trusted gatway ..."
> 
> Bryan
> 
It is very confusing to have such semantics. How is the peer node
to know all the subnets behind a VPN node?  I would much rather 
have the subnet (requiring security service) listed explicitly in 
the ID payload. 

Let me try and summarize the issues with the client ID payload.
I believe, the ID payload as it exists has the following limitations. 

    Transport mode: 
	IKE can negotiate for a client, irrespective of whether the 
	client is the same node as IKE or not.  
	
	ID type and identification data truly represent client 
	identification. Note, the ID type cannot be a subnet or range! 

	Policy can be communicated in a limited way, using the byte
	field for protocol and 2-byte field for transport identifier.

    Tunnel mode: 
	IKE and the tunnel end point (i.e., a VPN node) must be running
	on the same node. 
	
	ID type and identification data, in reality, are meant to identify
	the clients supported by the VPN node, and not the VPN node itself.
	I.e., the ID type and Identification data is being used to 
	communicate the VPN client policy.
       
	In other words, policy is communicated in a limited way using
	ID type, Identification data, protocol ID and transport port ID.


Clearly, the ID payload as it exists is overloaded to carry the semantics 
of ID and policy. But, it is workable with the above limitations. We need 
an unambiguous ID payload and a distinct policy payload. These are 
slated to be discussed in IPsecond.

Dan, if you would confirm or deny the above assertions, I would very much
appreciate. Thanks.

cheers,
suresh


References: