Subject: Re: [Ipsec] Question re INTERNAL_IP*_SUBNET attribute and SPD

From: Yoav Nir <[email-masked]>
Date: Sun, 2 Jul 2006 17:17:00 +0300

On Jun 28, 2006, at 7:11 PM, Stephen Kent wrote:

> At 6:22 PM +0300 6/28/06, <[email-masked]> wrote:
>> It's good to note that the INTERNAL_IP*_SUBNET attributes do not
>> necessarily affect the SPD at all. They contain the gateway's policy
>> about what traffic it would like to see sent via this tunnel... but
>> unless the client trusts the gateway unconditionally, it should not
>> change its SPD based on the information.
>>
>> But I guess you were considering the case where the client does
>> trust the information to be correct. I'd say that in most cases
>> it does not really change the SPD, but rather the routing table
>> (and thus source address selection). Traffic that is sent via the
>> tunnel uses the IP address assigned by the gateway as the source
>> address; traffic that should bypass the tunnel most likely would
>> use the IP address assigned by the local DHCP server.
>>
>> Best regards,
>> Pasi
>
> Thanks for clarifying the "clarification."  I was worried by the  
> suggestion that  sending this attribute via IKE caused a change to  
> the SPD.
>
> Steve
>

I'm not sure you can avoid it.

Since the client does not have the IP address assigned through the  
Configuration payload, we either have no triggering packet, or we use  
a source IP address of 0.0.0.0 like in DHCP.

Suppose the SPD entry has ANY for the local address and ANY for the  
remote addresses (what else can it have)  The relationships described  
in section 4.4.2.2 of RFC 4301 do not describe a way to get from  
"Any" to a list of ranges on either side, and the values on the  
triggering packet are no help either.  The SA that was created has a  
single assigned IP address as the local, and a list of ranges as the  
remote.

I don't see how we can make the client policy fit the model in RFC  
4301 unless we allow a temporary change in the SPD.

Yoav

_______________________________________________
Ipsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipsec

---

From: <[email-masked]>
Date: Mon, 3 Jul 2006 12:27:51 +0300

Yoav Nir wrote:
> > suggestion that  sending this attribute via IKE caused a change 
> > to the SPD.
> 
> Configuration payload, we either have no triggering packet, 
> or we use a source IP address of 0.0.0.0 like in DHCP.
> 
> remote addresses (what else can it have)  The relationships 
> described  in section 4.4.2.2 of RFC 4301 do not describe a way to 
> get from "Any" to a list of ranges on either side, and the values on 
> the triggering packet are no help either.  The SA that was created has

> a single assigned IP address as the local, and a list of ranges as the

> 4301 unless we allow a temporary change in the SPD.

When you're assigned a new IP address (either via INTERNAL_IP*_ADDRESS
configuration payload, or some other means such as manual
configuration), it might be necessary to create a new SPD entry that
specifies how packets to/from that address are to be protected.

Triggering based on outgoing packet is not possible before you get
the INTERNAL_IP*_ADDRESS, because before that your TCP/IP stack can't
send packets from that address -- so requesting the internal address
has to be triggered by some other means. After the address is assigned,
creation of additional CHILD_SAs can be triggered by outgoing packets
as well.

However, the original question (and Stephen's concern) was about
INTERNAL_IP*_SUBNET, not INTERNAL_IP*_ADDRESS; the former do not
necessarily cause any changes to the SPD. 

Best regards,
Pasi

---

From: Yoav Nir <[email-masked]>
Date: Mon, 3 Jul 2006 17:10:18 +0300

Let's look at an example.

The client connects with no triggering packet. It receives the IP  
address 192.0.2.1.  The gateway protects two subnets:  192.0.3.0/24,  
192.0.5.0/24 and policy dictates that separate SAs be used.

     CP(CFG_REPLY)
         INTERNAL_ADDRESS(192.0.2.1)
         INTERNAL_NETMASK(255.255.255.0)
         INTERNAL_SUBNET(192.0.3.0/255.255.255.0,  
192.0.5.0/255.255.255.0)
     TSi = (0, 0-65535, 192.0.2.1-192.0.2.1)
     TSr = (0, 0-65535, 192.0.3.0-192.0.3.255)

Upon receiving it, the client adds an SPD entry:

      local=192.0.2.1   remote=Any

An SPD cache entry:
     local=192.0.2.1    remote=192.0.3.0-192.0.3.255

And some route entries (using a Windows syntax):
     route add 192.0.3.0 mask 255.255.255.0 192.0.2.1
     route add 192.0.5.0 mask 255.255.255.0 192.0.2.1

It looks like it would work. I'm not sure that it's generally true  
that VPN tunnels are virtual interfaces that interact with the  
routing table, but for those clients that implement tunnels as  
interfaces, this would work.

Thanks

---

From: <[email-masked]>
Date: Mon, 3 Jul 2006 17:24:27 +0300

> interfaces, this would work.

I think most clients that support assigning IP addresses
with configuration payloads treat the VPN as some kind of
virtual interface. 

This is because the clients will want to use that address
as source address for TCP/UDP/etc. traffic, and at least in
the TCP/IP stacks I'm familiar with, that pretty much 
requires assigning the address to some kind of interface.

E.g. in Linux 2.6 kernel IPsec, you could assign the internal 
IP address to the "dummy" interface ("ifconfig dummy0 10.0.0.1")
and then create SPD entries that protect traffic from 10.0.0.1/32 
to 0.0.0.0/0 using a tunnel mode SA to the gateway.

(But this is not the same thing as treating IPsec tunnel
mode SAs or IP-in-IP tunnels as interfaces, as suggested 
in RFC 3884. E.g. in the Linux 2.6 example above, dummy0 
is not a tunnel, and is not specific to IPsec.)

Best regards,
Pasi