Re: SPD name entries & IKE

[vamsi <vamsi@intotoinc.com>]

Some implementation, including ours, identify the remote roaming user by 
their ID (ID in certificate
OR ID from the payload) and corresponding SPD policies are activated upon 
phase1 completion.
While activating the SPD policies, the Destiantion IP address of outbound 
policies and Source IP address
of corresponding incoming policies are changed to the remote user's IP 
address (Source  IP of phase1 first message).
Due to this, Quick Mode (QM) succeeds and finds the right SPD policy by 
matching with the selectors.

At the end of phase1 and phase2  SA termination and
if no phase1 is initiated by remote client for some duration of time, 
corresponding SPD policies are de-activated and go
to dormant state.

Due to this, I don't see any need for searching for SPD policy based on 
symbolic name, during QM.
It might offer other advantages, but for this scenario, I don't see the need.




At 01:17 PM 1/21/2004 -0500, Stephen Kent wrote:
>Folks,
>
>In revising 2401 we tried to more clearly describe how the SPD works, as 
>well as expanding it to cover new selector types, i.e., mobility header 
>and ICMP type & code values.
>
>In the course of this work we encountered a problem with the use of 
>symbolic names. The primary motivation for accommodating a symbolic name 
>in an SPD entry is to allow for an incoming SA creation request for a user 
>or machine for which no fixed Ip address is known a priori. Other possible 
>uses noted in 2401 included providing fine-grained access control for 
>individual users/processes on a multi-user system. However, this latter 
>case seems to be not a significant requirement based on existing practice, 
>right?
>
>In the primary case, the symbolic name in an SPD entry is a placeholder to 
>be replaced with the IP address associated with the IKE peer, when the 
>peer is authenticated as an authorized representative for the name. For 
>example, a road warrior might be authenticated using a cert. In that case, 
>the PAD (a newly articulated construct in 2401bis) would indicate that the 
>CA who issued the cert is authorized to issue credentials to all employees 
>(or maybe just to road warriors). Thus the ID asserted by IKE would be 
>verified as acceptable, relative to the CA, and the PAD indicates how the 
>ID asserted by IKE is verified, e.g., is it matched to the cert Subject 
>name, or simply accepted because the cert itself has been validated?
>
>However, even with the introduction of the PAD, we still have a problem in 
>this case. Specifically, how do we know that, for a specific SA 
>establishment activity, we should perform an SPD lookup using the ID from 
>IKE in the SPD as a substitute for the source IP address for inbound 
>traffic, instead of using the the address that appears in the traffic 
>selector payloads?  We need to use the latter address when we instantiate 
>the SPD cache and SAD entries, but we need to use the name for the initial 
>SPD lookup.
>
>What we discovered, in talking with several folks, is that there appears 
>to be no standard way for the IKE initiator to signal to a responder that 
>the ID is to be used for the lookup, vs. the selector payloads.  To me, 
>this suggests that we need yet one more minor modification to IKE to 
>accommodate this case. \
>
>Suggestions?
>
>Steve