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

[Mike Ditto <ford@incog.com>]

Dan Harkins <dharkins@tibernian.com> wrote:
 > On Fri, 29 Mar 2002 19:18:12 PST you wrote
[ ... ]
 > >			It is, I believe, not interoperable with other IKE
 > > implementations configured to segregate traffic between SAs based on
 > > port number style selectors.  Why is this?  It is because IKE was
 > > designed with a concept of "service" that is not compatible with our
 > > basic design.  
 > 
 > No, it's because this is still not an IPsec-compliant implementation.

I think I agree with your facts but you misconstrued my rhetorical
question.  I was asking, why didn't I just go ahead and create a fully
IPsec-compliant system?  The answer is that to do so would require a
complete redesign of a very complex product, (not only the parts related
to security protocols, but the whole policy design) and a loss of
functionality that I consider important.  This is the basis of my belief
that IPsec could and should have been designed with a looser coupling to
the policy representation, and that the current design of IPsec
precludes some reasonable implementations of network security products
(I say "reasonable," because one such implementation works quite well
with a non-IPsec form of network layer security).

 > You would have this problem with SAs that were manually created that
 > segregated traffic between SAs based on port and protocol. This only
 > looks like an IKE issue because that is where your non-compliance is
 > first shown.

I don't think that's true, because with manual keying I can map services
to SPIs with mutually agreed intended use.  It doesn't matter if the two
implementations have totally different ways of representing policy if
they are independently manually configured.  The problem is in trying to
express "intended use" over the wire using a protocol that can't
describe real services.


 > What you have proposed so far not only does not solve the problems with
 > the current approach (the desire to specify a protection of protocols that
 > float ports such that all the ports it uses are under the protection of a
 > single SA) it actually creates other problems (that have been discussed
 > earlier in this thread).

I'm aware that I haven't solved the problem.  My main point is to
suggest that the solution might not lie down the path of making a more
complex and comprehensive TS mechanism, but rather might involve finding
a way to avoid bringing TS into the protocol at all.

 > If what you have today is so wonderous and does not suffer from these
 > "limitations" then don't just sit and snipe and hope. Write a draft that
 > specifies how traffic should be classified without selectors. Then once
 > you've done away with selectors there will be no need for an SA establishment
 > protocol to use them.

If I refine my ideas enough to make that worthwhile, I'll do it.  I
admit I'm not there yet.  I wouldn't have brought it up at all except
that some others seemed to have arrived at similar ideas and I'm hoping
that we can come up with something that works for everybody.


					-=] Mike [=-