Re: Specification of tunnel/transport attribute in IKEv2

[Markku Savela <msa@burp.tkv.asdf.org>]

> From: Dan Harkins <dharkins@tibernian.com>

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

> This is not a firewall. It's an IPsec gateway.

You can do firewall with IPSEC (as far as access control is your
need).

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