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

Re: Automatic SPD Entry Creation for Remote Access IPSEC Clients

> 
> Hi Steve,
> 
> You posted a message to the IPSEC list (a while ago) that described
> dynamic creation of new inbound SPD entries for remote access clients
> with dynamically assigned addresses. (I.e. addresses unknown to the
> local system). Your rationale was that you needed to the new SPD entry
> to provide the final validation check for inbound packet processing.
> 
> Is this always necessary?
> 

I believe, so. 

> For example, please assume my inbound SPD states all UDP port 1701
> (L2TP) traffic from _ANY_ address must be encrypted using Transport
> mode ESP(3DES-SHA). Also assume that SPD entry requires SAD element
> derivation (creation) using the addresses, ports, etc from the packet.
> (This derivation mechanism is discussed on pages 14-15 of RFC 2401).
> 

So, you wish to have transport mode IPsec SAs established from
an LNS system to a variety of LACs that connect to it, based on
the packet selection criteria of src/dest address and src/dest ports.

I donot perceive LACs as the remote access clients, generally 
speaking. But, I guess, this will do for the example you are exploring.

> As multiple remote peers establish SA's, each of their SAD entries
> is created using their source IP address as defined by the IKE
> phase 2 identity. (I'm getting fuzzy here so please correct me if
> I'm wrong on this). All of those SAD entries are bound to the
> single SPD which contained the _ANY_ source address wildcard value.
> 
> Is this an acceptable alternative to dynamically creating SPD
> entries?
> 

OK, here is where the issue is. You are creating a new SA for each
new selection criteria of the packets. I.e., the security association
(SA) created refers to a specific variation of the policy (any address,
any port, my address, my LNS UDP port 1701), based on the packet
for which the SA is being created. 

Creating a new pair of (SPD entry, inbound/outbound SAs) is important
on the inbound to ensure that the SA attributes (ex: keys) are not being 
used by anyone that is not party to the SPD selection criteria.

Creating a new pair of (SPD entry, inbound/outbound SAs) is also important
on the outbound so you know which specific SA to use for an outbound
packet. 

> 
> Perhaps I can answer my own question. The specific packet that triggered
> the SA creation is not known in the _responding_ system therefore
> there is insufficient information to create the SAD element. That is
> why you recommended waiting until the first IPSEC packet arrives and then
> creating the SPD entry from that. 
> 

You create a new pair of (SPD, SAD) entries when IKE phase II ID is
received. I assume, this is what you meant by the first IPsec packet.

> Could you create the SAD entry and bind it to the wildcard source
> address SPD entry instead?
> 

Please see my comments earlier.

> -Ben McCann
> 
> -- 
> ---
> Ben McCann                              Indus River Networks
>                                         31 Nagog Park
>                                         Acton, MA, 01720
> email: bmccann@indusriver.com           web: www.indusriver.com 
> phone: (978) 266-8140                   fax: (978) 266-8111
> 

cheers,
suresh
References: