RE: Move TS to optional (RE: Don't remove TS from IKEv2)

[Stephen Kent <kent@bbn.com>]

At 6:01 PM -0800 3/22/02, Rajesh Mohan wrote:
>  >
>>  Any optional feature is one more decision that can be made differently by
>>  different implementors, breaking interoperability.  Not a good idea.
>>
>>  Moreover, that *doesn't* simplify the protocol.  Indeed, it
>>  complicates it,
>>  because now all analysis must consider two different cases (TS and no-TS).
>>
>
>I do not agree that no-TS feature will break interoperability. It really
>depends on how we define interoperability. When two gateways negotiate to
>not use TS, then the two gateways are said to interoperate as long as they
>establish an SA and are able to decrypt a packet that is encrypted. *** They
>have chosen to use a policy enforcer outside IPSec ***. So, traffic not
>flowing because of misconfigured policy enforcer should not concern this
>group.
>
>We do not need no-TS feature if IKEv2 can solve all cases. Can we configure
>IKEv2 such that between the same pair of host we have "ESP null for H.323"
>and "ESP for FTP"? If the draft cannot cover this case, then no-TS feature
>will be useful where it is needed.
>
>There are environments where people can trust all traffic through a tunnel.
>It can be used in those cases. We can have a firewall rule to encrypt all
>traffic going through some interface or accept only encrypted traffic
>through some interface. In a dynamic routing environment, this may be
>useful. People will find ways to use VPN if you do not make TS mandatory.
>With no-TS feature, we will have more port based VPNs. Making it optional
>does not hurt anyone. It will help us use VPNs in new ways.

it is important to remember that in developing a standard we try to 
accommodate a broad range of anticipated users, but we do not do so 
optimally. Making transmission of traffic selector info optional adds 
complexity to the system, because a compliant system has to be able 
to deal with this data, and to be able to deal with it's absence. I 
don't doubt that some folks might like to use some non-IPsec 
mechanism to achieve the same effect, but do we want to add 
complexity to the system in order to accommodate this set of 
prospective users?

Steve