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

[Mike Ditto <ford@incog.com>]

Some have proposed adding a way to redefine (broaden) an existing SA's
selectors with an additional exchange.  This does solve the problem that
the current TS mechanisms are not capable of expressing all commonly
used services.  But it's going even further down the complexity road.

"sankar ramamoorthi" <sankar@nexsi.com> wrote:
> One concern I have with the proposed approaches is the additional
> latency between discovery of the dynamic information and updating the
> peer with the dynamic information. Using any of the proposed mechanisms 
> (via IKE or external protocol), the latency may be unacceptably high
> for some type of traffic.

This is why I advocate that the protocol for broadening a tunnel's
traffic selectors consist of simply sending the packet that you want to
send.  This already has to be checked by the recipient for conformance
to its policy, so let it be an implicit request to "broaden" the tunnel.
No latency.

> Another alternative worth considering is to do policy change
> inband to ipsec traffic. After all, if a secure a channel has
> already been established with the peer, why not use the same channel
> for updating the selector information?

Right, and you don't even need a new protocol for the request (just send
an actual packet), or for positive responses (implied).  You only need
to define the error messages sent to reject the request.  I think a few
new ICMP codes would meet that need.  There is of course the problem of
choosing an appropriate SA in the reverse direction for the error
response.

Jan Vilhuber <vilhuber@cisco.com> wrote:
> A pre-cursor to this draft (that I was hashing out with some l2tp
> folks) had speculated on using specifiers like 'L2TP' or 'FTP' or
> "H.323" (IANA assigned, of course ;) in IKE.

The problem with that is that it's hard enough to codify and implement
those bletcherous protocols so that they work at all; much less trying
to then figure out what to write in an RFC to describe their traffic
pattern so that you can reference that in an IANA assignment for a token
like "H.323".  That's why I gave my example of one vendor implementing
"NetMeeting" and another vendor implementing "H.323".  They aren't the
same protocol, but if the applications work...that's good enough.  The
grotesque details of what packets are or aren't part of a particular
service should be left to the policy IMPLEMENTATION and out of key
management.

					-=] Mike [=-