RE: Don't remove TS from IKEv2

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

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.

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)

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

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.  

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

	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.

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.


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.  

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