RE: Don't remove TS from IKEv2

["sankar ramamoorthi" <sankar@nexsi.com>]

Hi,

IMHO,

I feel that TS are absolutely required and not having them
will lead to lot of interoperablity problems. I also feel that
IKEV2 definition of TS is rich and goes a long way to solve the
problems listed. Some additional things that would be nice to
have in ikev2 are
	o allow TSes to be modified by either initiator or responder
	o allow TS to be changed after the ipsec SA is established.
        This could be achieved using authenticated and reliable
        notification.


comments inline,

-- sankar --

> -----Original Message-----
> From: owner-ipsec@lists.tislabs.com
> [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Michael Choung Shieh
> Sent: Thursday, March 21, 2002 8:41 PM
> To: 'Dan Harkins'
> Cc: ipsec@lists.tislabs.com
> Subject: RE: Don't remove TS from IKEv2
>
>
>
> It seems easy that we can just transform the SPD to TS and done.
> Unforetunely, if the SPD is comlex, it's not easy to populate SPD
> consistently.
>
> My rationals:
>
> 1. IKE must bear the complex SPD in TS.

Yes - that seem to be best way for interoperable operation.
Also TSes clearly indicate how each side wants the traffic to be
restricted.

>
> 2. IKE interoperability is affected by imcompatible service
> definition, and
> the various ways vendors transform SPD to TS. (and users cannot fix it by
> adding additional SP)
>

At least looking at the TSes negotiated we can find out how
a peer is transforming SPD to TS. Not having it requires out-of-band
means to determine what the tunnel is negotiated for.

> 3. it doesn't work if users intend to have asymetric SPD, or change local
> SPD.

This problem can be addressed by enhancing IKE to allow changing a
selector after ipsec SA is established.

>
> 4. cannot support dynamic routing.
>
> and, if after go through so many troubles to transform SPD to TS and the
> only benefit is to detect mis-config SPD, I would suggest to put it as
> optional.  Puting it as optional can detect mis-configuration
> whenever it's
> needed, and there is no security impact.
>
>
>
> Here I show some scenarios that populate SPD to TS is not tedious, it may
> not work at all.
>
> a. a popular grouping features supported by many vendors
> 	source (S1 & S2 & S3), destination (D1 & D2), service (FTP & DNS) to
> use VPN
> 	It will generate 3 x 2 x 4 = 24 TS payloads.  (FTP = TCP port 20 &
> 21, DNS = TCP & UDP port DNS)
> 	so both sides need to transform these SPD to 24 TS.  Upon receive
> the chain of TS, sort it out and compare.
>    This is the easiest scenario since it can be done, just
> tedious (which I
> am fine as long as it can get right).
>
>
> b. If vendor B transform FTP and DNS to TS in different way (FTP=TCP port
> 21, DNS=TCP port DNS). then IKE won't work.  These two are
> well-known so we
> can probably document it.  However, how about all other applications out
> there?  H323?  Now IKE becomes a tool to check the interoperability of
> "service" (SPD) among vendors.

You seem to be making a case for having TS. In the absence of TS, the two
parties can have different interpretations and end up with varying TSes
as you describe. Worst, in the absence of TS each side may not be aware the
other side's interpretation which seems to be a bigger problem to me.

>
> 	so the definition of "app service" (spd) and the method of transform
> complex spd to TS must be standardized before IKE can work.

not necessarily. Having a list of TSes and allowing for the TSes to be
changed during and after QM negotiation allows ipsec traffic to flow
even if one side's interpretation is more stringent than the other one's

traffic flow is just restricted - looking at the TS negotiated, clearly
indicates what the interpretation was. Having just an 'app service' identity
requires standarization of what the service means for IKE to work in an
interoperable way.
>
> 	Besides, the difference on SPD may not a problem.  without zone
> transfer, DNS on UDP port 53 may work just fine.
>
> c.  a good example for asymetic SPD is the "opportunistic sa".
> if SPD of A
> is TELNET, SPD of B is ANY.  when A initiate IKE to B, IKE is up
> and telnet
> go through.  However, after IKE is up, non-telnet traffic cannot
> come from B
> to A.  I think it totally defeat the purpose of TS, but people seems fine
> with it.
>
> 	Another problem is we cannot change inbound SPD without totally
> shuting down tunnel.  If there are 500 remote users out there and admin
> wants to change inbound policy (eg. remove one server from spd),
> he needs to
> change all users' SPD before he can change tunnel setting.

This problem can be circumvented if we allow for the possiblity for
TS to be changed after the SA is established (using authenticated
notification
messages).

>
> d. if the ipsec gateway has 2 interfaces which connect to
> different routers.
> traffic from router 1 (from interface 1) go to tunnel 1 and traffic from
> router 2 (from interface 2) go to tunnel 2.  Now even set TS as 0/0 won't
> work.  Reason is simple - SPD may include interface as an attribute so the
> 5-tuple TS won't work.

missing the point on this one. How is it related to IKE?
>
>
> sorry for the lengthy messages.  I just want to show puting the
> knowledge of
> SPD in IKE is not an good idea.  We have enough interoperability
> in IKE, why
> bother to test the interoperability of SPD in IKE.

Not having TS or having policy id for TS actually limits interoperbility.
It seems to work well and allows for a richer definition of TS
only when both ipsec peers interpret the id in the same manner.
That calls for a lot more standarization work, which is
beyond the scope of IKE.



>
> Michael Shieh
>
>
> > -----Original Message-----
> > From: Dan Harkins [mailto:dharkins@tibernian.com]
> > Sent: Thursday, March 21, 2002 3:14 AM
> > To: Michael Choung Shieh
> > Cc: ipsec@lists.tislabs.com
> > Subject: Re: Don't remove TS from IKEv2
> >
> >
> > On Wed, 20 Mar 2002 19:41:38 PST you wrote
> > >
> > > 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.
> >
> > Whatever was in the your SPD that matched the packet that caused the
> > negotiation to happen in the first place. That should be what your TS
> > payloads represent.
> >
> > > These are all customer request features.  right now I can
> > only put 0 in
> > > proxy_id (and future TS) and screw up my tunnel.
> >
> > I'm assuming you are able to populate your SPD correctly (since this
> > discussion is not to change the representation of selectors).
> > If your SPD
> > can somehow be properly configured to allow NAT from
> > different pools or
> > H.323 to be IPsec protected it should not be too difficult to do this
> > either. Whatever got sent up with the "acquire" (a PF_KEY term but you
> > should have a symantically equivalent function) is what you use.
> >
> >   Dan.
> >