Re: Specification of tunnel/transport attribute in IKEv2

[Dan Harkins <dharkins@tibernian.com>]

On Tue, 21 May 2002 09:19:22 +0300 you wrote
> 
> > Notification of Joe is the prudent thing to do since he is not a
> > "cracker", he is a legitimate user with old/stale/incorrect
> > policy. By just blackholing his packets you have relegated him to
> > oblivion. You obviously have not dealt with real world use of this
> > technology.
> 
> You can either black hole or notify. If gateway 192.168.10.1
> has policy
> 
>    10.1.17/24 <---> 172.21.16.5, protect via 172.21.16.5
>    any <--> any, drop
> 
> and joe (172.21.16.5) tries for 10.1.5.5, then in my world
> 
> 1) IKE establishes phase I between 172.21.16.5 and 192.168.10.1
> 
> 2) Using this, Joe succesfully negotiates SA's for communicating with
>    10.1.5.5
> 
> 3) Joe's encrypted packets to 10.1.5.5 are successfully decoded at
>    192.168.10.1, but they fail to match the policy => gateway knows
>    there is policy mismatch or cracking attempt. It can either
> 
>    - drop the packet (black hole), or
> 
>    - pass a note to the local IKE, which could decide to send a
>      notification to the joe's IKE using the existing phase I.

But you've been arguing all along that IKE should not be doing this.
You've been saying that all it should do is obtain a shared key period
full stop. 

> > > joe's SG (172.21.16.1) negotiates SA's for joe (172.21.16.5), and the
> > > resulting SA has the following info
> > > 
> > >    protocol=any
> > >    src port=any
> > >    dst port=any
> > >    proxy=172.21.16.5
> > 
> > Proxy? Where did that come from? I thought IKE was not permitted to provide
> > any clarifying information in your view.
> 
> Proxy is better word what in IKEv2 TS is address (or ranges or
> whatever). SA destination address is always the address of the other
> end point (joe or 192.168.10.1). IKE seems to require the source
> address for SA too, but this is not really a requirement -- on a
> multihomed node, one could use same SA for all of its source
> addressess).

But, but, but.... Who cares what the term is. Where is it coming from?
You've been arguing that IKE should not be doing this. 

Since you are now talking about having key management sending error messages 
indicating mismatched policy and providing clarifying information for the
selector to the peer I guess you have changed your mind.

  Dan.