Subject: Re: framework draft v07 uploaded to IETF

From: "Yang, Lily L" <[email-masked]>
Date: Mon, 11 Aug 2003 10:50:46 -0700

For the security section, we propose the following changes to address both the unicast and multicast issue. I will be uploading a new revision of the document with these changes today.
Please take a quick look and let me know if you have further comments.
Thanks,

Lily

---------------------
1) Section 7.2: Clarify on the recommendations of TLS, IPSec & single-box, calling out unicast and multicast explicitly.
[old text]
"We highlight two existing security protocol solutions, namely IPsec 
(IP Security) [14] or TLS (Transport Layer Security) [13]. TLS 
works with reliable transports such as TCP or SCTP, while IPsec can 
be used with any transport (UDP, TCP, SCTP). Both TLS and IPsec can 
be used potentially to satisfy all of the security requirements for 
ForCES protocol. 
It is important to realize that even if the NE is in a single-box, 
the DoS attacks can still be launched through Fi/f interfaces. 
Therefore, it is still important to have counter-measurement as 
stated in 1.1.9 for DoS while authentication, confidentiality and 
integrity can be provided by the physical security of the box."
[new text]
"We review two existing security protocol solutions, namely IPsec 
(IP Security) [14] or TLS (Transport Layer Security) [13]. TLS 
works with reliable transports such as TCP or SCTP for unicast, while IPsec can 
be used with any transport (UDP, TCP, SCTP) and supports both unicast and multicast. Both TLS and IPsec can 
be used potentially to satisfy all of the security requirements for 
ForCES protocol. Other approaches may be used as well but are not documented here.
When ForCES is deployed between CEs and FEs inside a box, 
authentication, confidentiality and integrity may be provided by the physical security 
of the box and so the security mechanisms may be turned off, depending on the network
topology and its administration policy. However, it is important to realize
that even if the NE is in a single-box, the DoS attacks as described in Section 7.1.8 
can still be launched through Fi/f interfaces. Therefore, it is important to 
have the corresponding counter-measurement in place even for single-box deployment."
2) Section 7.2.2: Using TLS with ForCES
At the beginning of the first paragraph:
[old text]
"TLS [13] can be used if a reliable transport such as TCP or SCTP is 
used for ForCES over Fp interface..."
[new text]
"TLS [13] can be used if a reliable unicast transport such as TCP or SCTP is 
used for ForCES over the Fp interface..."
3) Section 7.2.3. Using IPsec with ForCES 
1st paragraph:
[old text]
"IPsec [14] can be used with any transport protocol, such as UDP, 
SCTP and TCP over Fp interface for ForCES. We recommend using ESP 
in transport mode for ForCES because message confidentiality is 
required for ForCES and the communication between the CE and FE is 
point-to-point. " 
[new text]
"IPsec [14] can be used with any transport protocol, such as UDP, 
SCTP and TCP over Fp the interface for ForCES. When using IPsec, we recommend using ESP 
in transport mode for ForCES because message confidentiality is 
required for ForCES."
Also add the following paragraph after the 2nd paragraph to call out both unicast and multicast:
[new text]
"IPsec can support both unicast and multicast transport. When multicast is used,
IPsec can be used with manual keying with no replay protection and no automatic rekeying. This meets 
the confidentiality and integrity requirements. Multicast-based solutions relying on IPsec should specify how 
rekeying and replay protection are provided."

> -----Original Message-----
> From: Putzolu, David 
> Sent: Friday, August 08, 2003 4:30 PM
> To: [email-masked]
> Subject: Re: framework draft v07 uploaded to IETF
> 
> 
> Jamal has correctly identified that the current draft seems
> to primarily speak to unicast, when there is not a demonstrated
> consensus that unicast is the only solution.  As such, I'd 
> like to request the authors edit the text to address both 
> multicast and unicast equally well in the recommendations -
> both security recommendations and in any other recommendations
> the document makes.  Explicitly stating that either or both 
> of unicast and multicast may be used in ForCES protocol design 
> would also be appropriate. 
> 
> In the security section in particular, recommendations about 
> *how* to use standard security solutions (e.g. TLS for unicast, 
> IPSec for unicast and multicast) are useful and relevant 
> information and should be included.  Recommendations for
> actually *using* a specific security protocol should not be 
> included as they are decisions that will be made in ForCES 
> protocol design & selection.
> 
> Finally, I would request that we stay away from issues of
> opinions and personalities, instead focusing on arriving at
> the best possible technical solution.
> 
> Thanks,
> David
>

---

From: Jamal Hadi Salim <[email-masked]>
Date: Mon, 18 Aug 2003 11:06:33 -0400

Lily,

The text is still unsatisfactory.
You did not change the text in regards to "manual keying with no replay
protection and no automatic rekeying" that i pointed out earlier.

The only open issue in multicast security (that may still be considered
as work in progress) is that of source-authentication. This is being taken
care of by the TESLA prorotocol for example. That issue is however not to
be considered until protocol evaluation time (if source-authentication
ends up being used).

Perhaps the best thing to do is for the authors of the draft to read the
MSEC Arch document and the GKM Arch document (both in last call for RFC
status) since we a renot getting anywhere on this. Best of all lets talk
to the MSEC folks - I was just checking my email and it seems they have
been rechartered.If you dont wanna read the prescribed docs
then please cc them in your response at:
[email-masked]

cheers,
jamal