Re: Specification of tunnel/transport attribute in IKEv2

[Jan Vilhuber <vilhuber@cisco.com>]

Sure sounds like an administrative nightmare (as well as wasted
bandwidth) to me, when we could simply do it via negotiation in an
automated fashion.

jan


On Fri, 24 May 2002, Markku Savela wrote:

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

 --
Jan Vilhuber                                            vilhuber@cisco.com
Cisco Systems, San Jose                                     (408) 527-0847

http://www.eff.org/cafe