RE: Is TS agreement necessary?

["Rajesh Mohan" <Rajesh.Mohan@nexsi.com>]

Hi Mike,

> 
> 
> Rajesh Mohan writes:
>  > Say, we have this special box made to be used in data 
> centers. We have regular IPSec complaint box in corporate 
> network. It will be convenient for the administrator at data 
> center to tunnel all traffic of a particular VLAN to the 
> corporate network. He does not care what network is at the 
> remote end. On the other end, the corporate administrator has 
> well defined selectors for the tunnel to the cage.
>  > 
>  > In this unsymmetric setup, having no selectors at IPSec 
> (and a way to negotiate this in IKEv2) is useful.
> 
>   Ok, I'm probably in left field here, but what you seem
>   to be describing is a completely permissive traffic
>   selector, not a lack of one. What's the problem here?
> 

There are two things I did not understand in your reply, "left side" and "permissive traffic selector". The first one probaly does not matter :-). I am not sure about the second. Anyway, I will try to clarify myself further.

There were two proposals so far to solve problems caused by having static selectors in IPSec (and hence IKE). The first was to not have selectors and the second is to have dynamic selectors.

In the case of dynamic selectors, the selectors will be expanded based on the type of traffic flow or the traffic received through the tunnel.

In the case of no selectors, the traffic enforcer is actually outside IPSec. When we have a option to not have selectors in IPSec, the decision to tunnel or not can be part of (say) firewall rules. When I say selectors should be optional, I do not mean that implementation of selectors be optional. IPSec complaint implementations should support selectors but there should be a way to setup a tunnel without actually specifying a selector.

The example I gave was to illustrate a case where having static selectors does not help. There were other examples before. I am trying to convince that selectors should be optional/dynamic.

- Rajesh M







> 		Mike
>