Re: Specification of tunnel/transport attribute in IKEv2

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

> From: Paul Hoffman / VPNC <paul.hoffman@vpnc.org>

> - need some policy negotiation outside of IKE before packets start
> to flow

Sort of, administrators of both sides have to agree to allow the
packets to flow. Then, both sides modify their policies accordingly. I
don't see any need for "policy negotiation protocol" between end
hosts.

I do see that sometimes a general IPSEC policy exchange format
might be a useful thing. A policy described in this notation could be
transferred to the users via different methods (email, http, etc).

> - need some policy announcement when bad packets are received 
> ("you're sending me packets that I have no intention of passing to 
> the inside network")

Not policy announcement. Just optional notification from one IKE to
another. This would alert the sender that there is "black hole".

1) Sends encodes the packet with SA(s)

2) Receiver successfully decodes the packet with SA(s)

3) Receiver checks that the uncovered plain packet matches the policy
   (as described in RFC-2401).

4) If packet does not match the policy, then there is a policy
   mismatch and a potential black hole (or cracking attempt). A
   notification can be sent to all key management servers. This notice
   could contain selector data from the packet and SA(s). IKE (or any
   other key manager) receive this message and from it can deduce
   whether the problem SA's are negotiated by it. If so, it can use
   the phase 1 session to pass the appropriate information to the
   other end.

5) Upon receiving the notification, the sender knows that it's packets
   are not accepted. Solving the problem requires human
   intervention.

IKE can do above without any knowledge about the actual policy.

This way even handles the black holes, that current IKE does not
detect: sender sends packets using wrong SA (like, negotiate SA for
telnet traffic, but use FTP over it).