RE: Don't remove TS from IKEv2

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

SPD (so is TS) may be different from
1. misconfig
2. intended asymetric SPD (example in previous email)
3. different interpretation of applicatiion services among vendors

when mismatched TS is found, IKE won't know which one it is.  so
a. fail IKE and don't support (2)
b. IKE suceed.  when data traffic is rejected, check SPD (or log for
negotiated TS as Sankar suggested).

current practice is (a).  I am suggesting (b).

more comments inline.


Michael Shieh


> -----Original Message-----
> From: sankar ramamoorthi [mailto:sankar@nexsi.com]
>	  
> 		[ .... skip ......]
> >
> > 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?

if users want 2 tunnels between gateway A and B.  B is a multihome gateway
connected to 2 routers as mentioned above.  To create 2 tunnels between A
and B, B should send TS as(0.0.0.0/0, interface 1) for tunnel 1 and
(0.0.0.0/0, interface 2) for tunnel 2.  current TS format cannot support it.

one might argument that he can put more stringent subnet instead of
(0.0.0.0/0). However, it means when routing changes beyond original TS,
tunnel will be down until both sides changes their tunnel setup.

Why users want to do 2 tunnels?  a good reason is to prevent oracle attack.


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

 
The "sa id" is local agreement between 2 endpoints (along with tunnel
creation agreement).  There is no need for standardization.  

> which is beyond the scope of IKE.

I think the interoperability and definition of application services among
vendors is also beyond the scope of IKE.  Unfortunely, IKE is doing it
through TS.  should we put it as optional?


>