[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Simplifying IKE

To: Michael Richardson <mcr@sandelman.ottawa.on.ca>
Subject: Re: Simplifying IKE
From: Michael Thomas <mat@cisco.com>
Date: Fri, 26 Oct 2001 12:50:17 -0700 (PDT)
Cc: Jun-ichiro itojun Hagino <itojun@iijlab.net>, ipsec@lists.tislabs.com
In-Reply-To: <200110252243.f9PMhDp00539@marajade.sandelman.ottawa.on.ca>
References: <20010814164122.68A287BA@starfruit.itojun.org><200110252243.f9PMhDp00539@marajade.sandelman.ottawa.on.ca>
Sender: owner-ipsec@lists.tislabs.com

Michael Richardson writes:
 >     Jun-ichiro> 	now I believe that we should avoid piggybacking the binding
 >     Jun-ichiro> 	updates onto normal packets.  if we treat them separately, we can
 >     Jun-ichiro> 	decide IPsec policy completely in a independent manner.
 > 
 >   I feel uncomfortable about this.
 >   I'm not sure why yet.

The problem with binding update piggybacking is
that you have a single IP packet which may, in
fact, have two different protection domains. That
is, the binding update may require authentication
in one realm, which the final payload may require
authentication in another. Currently, there is no
way to express such a rule in the SPD, nor key it.

IPsec is the first one that tripped over this, but
QoS is also negativey affected by piggybacking.
This shouldn't be surprising: IP expects that you
put messages with different functionality into
different packets. Opening this pandora's box is
IMO a generally bad idea.

	      Mike

References:

Re: Simplifying IKE

From: Michael Richardson <mcr@sandelman.ottawa.on.ca>

Prev by Date: Re: Status of ID: IPsec Flow Monitoring MIB
Next by Date: RE: Status of ID: IPsec Flow Monitoring MIB
Prev by thread: Re: Simplifying IKE
Next by thread: Does anyone care about IPcomp with IKE? (IPcomp=IP compression)
Index(es):
- Main
- Thread