Subject: RE: [Softwires] Control and data plane

From: "Durand, Alain" <[email-masked]>
Date: Mon, 16 Jan 2006 09:00:34 -0500

>From: [email-masked] on behalf of JORDI PALET MARTINEZ
>Sent: Mon 1/16/2006 8:31 AM
>To: [email-masked]
>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.
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.

    - Alain.

_______________________________________________
Softwires mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/softwires

---

From: "Spencer Dawkins" <[email-masked]>
Date: Mon, 16 Jan 2006 08:27:14 -0600

FWIW, "control plane" is sufficiently overloaded and overused that it might 
be worth using the phrase "softwire mechanism", as Alain did when explaining 
what the control plane is. Any thoughts on this?

Spencer

----- Original Message ----- 
From: "Durand, Alain" <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Sent: Monday, January 16, 2006 8:00 AM
Subject: RE: [Softwires] Control and data plane

>covered by the 2nd sentence ...

The "control' plane is the softwire mechanism. The data plane is made of the 
tunneled data.
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...

Both and neither.

    - Alain.

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Mon, 16 Jan 2006 16:23:46 +0100

Hi Alain,

See below.

Regards,
Jordi

> De: "Durand, Alain" <[email-masked]>
> Responder a: <[email-masked]>
> Fecha: Mon, 16 Jan 2006 09:00:34 -0500
> Para: <[email-masked]>, <[email-masked]>
> Conversación: Control and data plane
> Asunto: RE: [Softwires] Control and data plane
> 

Agree, that was my understanding.

>> Moreover, are we requiring encryption or just authentication ?

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.