RE: Don't remove TS from IKEv2

[Stephen Kent <kent@bbn.com>]

At 8:40 PM -0800 3/21/02, Michael Choung Shieh wrote:

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

The new proposals for how to express TS's would allow all this 
traffic to be mapped to a single SA, if that is the intent.  One 
cannot do that now. Also, your terminology here seems to be a bit 
off.  2401 does not describe support for multiple individual values 
for a selector in an SPD entry. We intend to make this a requirement 
going forward. If one provides a management interface that presents 
this view, there is a potential problem that arises from the mismatch 
between what can be expressed in the SPD and what IKE can negotiate, 
something we tried to avoid.

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

I think what you are describing is again a mismatch between what one 
can express in the SPD vs. what IKE can negotiate. It should be a 
goal of our current efforts to close this gap as we improve the 
expressiveness of the SPD and sone of IKE.

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

This example seems to be incomplete. SPDs have independent, 
directional entries. A could be authorizing outbound Telnet 
connections, but rejecting inbound Telnet connections. If so, then 
asymmetric SPD entries for A&B might correctly express the intent of 
each site. It's not clear from your example what the intent was, so 
it's not clear that you have cited a real problem.

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

Where in 2401 do you find the basis for this requirement, as opposed 
to an implementation choice in a specific product?

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

I'm afraid the example is too terse for me to understand.  But, since 
we are also working on revisions to 2401 that will deal with the 
question of when routing is performed relative to IPsec processing, 
we may be able to address issues of this sort going forward.

Steve