>
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.