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

Re: Non-IP type Client IDs

I think a critical point is being overlooked, or perhaps just not being
voiced: policy selectors are not the same as SA selectors. That is, you
may use one thing to select the appropriate policy, e.g. FQDN, DN, etc.,
and use something entirely different to map flows into SAs. You really
have no choice but to use flow identifiers such as IP addresses,
protocol, and ports to map active flows to the appropriate SA, but you
may not know these when constructing your policy.

The remote user presents a good example. In many cases, the remote
user's IP address is dynamically assigned somehow, and in configuring
policy, you have no idea whatsoever as to what this will be. You MUST
rely on some other mechanism. Furthermore, the address used in the phase
2 SA may not be the same as the one assigned by the ISP and used to
negotiate in phase 1, in which case you have the effect of superimposing
a security gateway with the ISP address between the user and the ISP, as
in the following diagram:

         USER SYSTEM                                               CORP
NET
       +--------------------------------------+                      
|10.0.1.x
       |                       |  ISP IP:     | internet +-------+    |
       | virtual IP: 10.0.1.26 | 192.x.y.z    |==========| sgw  
|----|     +----+
       +--------------------------------------+          +-------+   
|-----|    |
                                                                           
+----+

In this case, the user has a virtual presence on the internal net, and
packets containing the virtual IP are tunneled to the sgw, with the ISP
IP in the outer header. I grant that in this case the phase 1 SA is
uniquely tied to the phase 2 SA, so that the phase 2 ID could be
omitted, as it is redundant to specify the DN again (assuming that is
what was used to authenticate the phase 1 SA). However, that's different
than REQUIRING that the phase 2 ID be only IP addresses.

Another question I have is, do we really want to close the door on the
possibility that someday we might want to add a mechanism whereby users
somehow authenticate themselves to the sgw, and the sgw subsequently
passes on this disjoint DN in a common phase 1 SA (as a phase 2 ID
payload)? 

Scott
Follow-Ups: References: