RE: [Softwires] Control and data plane

Jordi,

This discussion is a very good one to have when discussing the solution space.
Note how this is related to the issue of softwire signaling: inbound or out-of-band with the data.

   - Alain.

________________________________

From: softwires-bounces@ietf.org on behalf of JORDI PALET MARTINEZ
Sent: Mon 1/16/2006 10:23 AM
To: softwires@ietf.org
Subject: Re: [Softwires] Control and data plane

Hi Alain,

See below.

Regards,
Jordi

> De: "Durand, Alain" <Alain_Durand@cable.comcast.com>
> Responder a: <alain_durand@cable.comcast.com>
> Fecha: Mon, 16 Jan 2006 09:00:34 -0500
> Para: <jordi.palet@consulintel.es>, <softwires@ietf.org>
> Conversación: Control and data plane
> Asunto: RE: [Softwires] Control and data plane
>
>> From: softwires-bounces@ietf.org on behalf of JORDI PALET MARTINEZ
>> Sent: Mon 1/16/2006 8:31 AM
>> To: softwires@ietf.org
>> Subject: [Softwires] Control and data plane
>
>>
>
>> Hi all,
>>
>> I'm trying to clarify myself about this:
>>
>> 3.11.2.  Privacy, Integrity, and Replay protection
>>
>>   The softwire Control and/or Data plane MUST be able to provide full
>>   payload security (such as IPsec or SSL) when desired.  This
>>   additional protection MUST be separable from the tunneling aspect of
>>   the softwire mechanism itself.  For IPsec, default profiles MUST be
>>  defined. [draft-ietf-v6ops-ipsec-tunnels] provides guidelines on
>>   this.
>>
>> I'm starting to think that if I can't understand this text being 100% sure
>> about what we want to say, then is not clear enough ;-)
>>
>> My question is, when we say contral and/or data plane, we are referring to
>> the softwire protocol itself including any handshaking etc. ?
>>
>> So the handshaking is the payload and then is data, or data is the tunnel.
>>
>> Because if data is the tunnel (which is what I think), then it is already
>> covered by the 2nd sentence ...
>
>
> The "control' plane is the softwire mechanism. The data plane is made of the
> tunneled data.

Agree, that was my understanding.

> My reading of the second sentence is that there is no a-priori restriction on
> the way this security is achieved. For example, one can decide to protect the
> control plane
> and not the data plane or vice versa, and this should be doable regardless of
> the tunneling
> control mechanism softwire will use...
>
> Does this makes things clearer?
>
>> Moreover, are we requiring encryption or just authentication ?
>
> Both and neither.

So the choices are:
1) Apply encryption or authentication or both together to the data plane
(the tunnel)
2) Apply encryption or authentication or both together to the control plane
(the mechanism)

I'm sure about 1), but not sure about 2 (at least for the encryption part),
it will enforce to use, for example, an IPsec tunnel for the softwires
protocol, that is already tunneling some data, and may be using IPsec
itself.

Do we really need all that ? May be we need to consider if there is a severe
threat if not requiring encryption. Authentication seems easy to support in
the protocol itself w/o the need to use one more tunnel (an IPsec one).

>
>     - Alain.
>
> 
>

**********************************************
The IPv6 Portal: http://www.ipv6tf.org

Barcelona 2005 Global IPv6 Summit
Slides available at:
http://www.ipv6-es.com

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.

_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www1.ietf.org/mailman/listinfo/softwires

_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www1.ietf.org/mailman/listinfo/softwires