RE: Don't remove TS from IKEv2

[Michael Choung Shieh <mshieh@netscreen.com>]

TS does detect mis-config for simple scanario.  However, it falls short on
more complex cases:

1. FTP, DNS, H323.  (btw, can someone show me what the correct TS should be
for FTP and H323?  I still don't know how to do it correctly even for FTP)
2. dynamic routing.
3. NAT from several pools (or determined by routing)
4. change inbound local security policy without shuting down whole tunnel or
wait for peer's approval.

These are all customer request features.  right now I can only put 0 in
proxy_id (and future TS) and screw up my tunnel.

If TS payload can only support simple scenario, and only provide the benefit
of misconfig detection, then we should put it optional (so one can detect
misconfig if they want).

It was pointed out the responder can have wider TS to do opportunitic sa.
The problem of it is it only works for client-server case and fails in
peer-to-peer case.  Even in client-server scenario, most likely the server
(responder) has smaller range of TS (it probably only allows FTP).   The
client probably doesn't care the TS at all.  I will be happy to hear a use
case of it.

Michael Shieh





> -----Original Message-----
> From: Dan Harkins [mailto:dharkins@tibernian.com]
> Sent: Wednesday, March 20, 2002 4:57 PM
> To: Mike Ditto
> Cc: warlord@mit.edu; sommerfeld@east.sun.com; mshieh@netscreen.com;
> ipsec@lists.tislabs.com
> Subject: Re: Don't remove TS from IKEv2 
> 
> 
> On Wed, 20 Mar 2002 15:36:17 PST you wrote
> > Derek Atkins <warlord@MIT.EDU> wrote:
> > > The issue here is that you don't want to create an SA that will
> > > end in a black hole.  If you create an "opportunistic" SA with
> > > someone you've never heard of before, you need to know what your
> > > peer will accept over the SA.  If your peer will only accept,
> > > e.g. packets to tcp/80, then you know you shouldn't send anything
> > > else.  This keeps you from creating a black hole.
> > 
> > I see, but I don't see that this is useful.  If it's my intention to
> > negotiate a tunnel with you and then send through it 
> packets that you
> > won't accept, there is no reason to treat that differently than if I
> > just sent the unacceptable packets to you outside of the 
> tunnel.  Drop
> > the packets or send an ICMP error.
> 
> If I knew that was your intention I wouldn't establish the 
> SAs with you
> in the first place. Assuming you're not doing that, then how 
> do you know
> what the problem is when packets do not flow? You want to send a wider
> variety of packets to me protected by this SA than I want to 
> accept from
> you. With the TS payloads you we can know this and we can know the
> entire subset of what you want to send and what I'll accept.
> 
> > In addition to believing that the feature is not useful, I also
> > believe that it is not possible to do in general.  Either alone is
> > reason enough to drop it; I think both together clinch it.  :-)
> 
> If what you are saying was true I'd agree but I believe it is 
> both useful
> and possible to do. Useful because I have been on the receiving end of
> a report from the field with the specificity of "the pings 
> stopped" and
> it was just this capability that was used to figure out why. 
> Possible to
> do because I've done it.
> 
>   Dan.
> 
> 
>