Re: [Rmt] AD review of draft-ietf-rmt-bb-lct-revised-07

[Mark Watson <[e-mail]>]

On the last point, since ALC is the more 'well-known' layer, and since LCT
cannot be used 'stand-alone' would it be acceptable in the LCT draft to just
state the security issues that must be addressed by any PI based on LCT and
refer to ALC for an example ? This would avoid either duplicating the text
or confusing people by moving the existing text from ALC to LCT.

...Mark 


On 2/10/09 7:41 AM, "Vincent Roca" <[e-mail]> wrote:

> Hello Mark,
> 
> A few answers concerning TESLA (points 2 and 3 in your email):
> 
> 2- Yes this is a draft. It passed a first WGLC in september, two
>    updated versions have been submitted then, and a second WGLC should
>    be issued soon. If you need an RFC, you can cite RFC 4082:
> Timed Efficient Stream Loss-Tolerant Authentication (TESLA):
> Multicast Source Authentication Transform Introduction
> 
> 3- You're right, it is not specific to ALC but applies to any PI built
>    on top of LCT. We decided to mention only the currently existing
>    PIs for simplicity purposes (IMHO, many people get already confused
>    by FLUTE versus ALC, no need to add another acronym/layer).
> 
> Cheers,
> 
>   Vincent
> 
> 
> Mark Watson wrote:
>> Magnus, all,
>> 
>> Regarding the Security Considerations and your comment on Section 7, I have
>> some questions for the group:
>> 
>> 1) should we just update the text here in LCT to align with ALC ? Or, in
>> fact, should that text be in only one of the documents with a reference from
>> the other ?
>> 
>> In the latter case, the text should probably be in LCT with a reference from
>> ALC. If there is anything truly ALC-specific it can stay in ALC.
>> 
>> 2) Regarding the TESLA in RMT work, I understand this is a draft right now.
>> Do we need a reference from ALC/LCT to that ?
>> 
>> 3) The work in MSEC is called TESLA for ALC and NORM: is it specific to ALC
>> or would it apply equally to anything built on LCT ?
>> 
>> I propose to address the remaining comments as noted inline below.
>> 
>> ....Mark
>> 
>> 
>> 
>> 
>> On 1/23/09 6:59 AM, "Magnus Westerlund" <[e-mail]>
>> wrote:
>> 
>>> Hi,
>>> 
>>> I have reviewed the LCT builidng block and have the following comment.
>>> 
>>> 1. Section 3, page 7: "Some possible
>>>    multiple rate congestion control protocols are described in
>>>    [VIC1998], [BYE2000], and [LUB2002].  A possible single rate
>>>    congestion control protocol is described in [RIZ2000]."
>>> 
>>> To my knowledge WEBRC (RFC 3738) is the only actually standardized (as
>>> experimental) that is suitable for the scalability LCT is intended for.
>>> Can we please include a reference and indicate that this actually is the
>>> currently recommended. References to any other potential solution is okay.
>> 
>> Ok.
>> 
>>> 2. Section 4.1, page 11:
>>> "the Source-
>>>    Specific Multicast (SSM) model as defined in [HOL2001]."
>>> 
>>> RFC 4607 is available and specifies SSM. Isn't that a more suitable
>>> reference?
>> 
>> Yes.
>> 
>>> 3. Section 4.3:
>>> Also here I think the references and discussion should be updated to
>>> what is actually available.
>> 
>> Ok.
>> 
>>> 4. You clearly forgotten to check the ID-nits on this document:
>>> http://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft-ietf-rmt-bb-
>>> lc
>>> t-revised-07.txt
>>> 
>>> Then you would have seen that you have references to 3 obsoleted RFCs:
>>> RFC 1889, RFC 2327, and RFC 2423.
>> 
>> I don't think these were nits when the document was submitted ;-) I'll
>> address them.
>> 
>>> It also indicates that you are missing the actual entry in the reference
>>> section for RFC 1305.
>>> 
>>> 5. Section 5.2.1:
>>> "   All senders and receivers implementing LCT MUST support the EXT_NOP
>>>    Header Extension and MUST recognize EXT_AUTH and EXT_TIME, but MAY
>>>    NOT be able to parse their content."
>>> 
>>> MAY NOT is not defined in RFC 2119. Please rephrase.
>>> 
>> 
>> ok: "...but are not required to be able to parse their content."
>> 
>>> 6. Section 5.2.2:
>>> 
>>> "     When the SCT-Low flag is set, the associated 32 bit time value
>>>       provides an unsigned integer representing a multiple of 1/2^^32 of
>>>       a second, in order to allow sub-second precision.  When the SCT-
>>>       Low flag is set, the SCT-High flag MUST be set too.  In the
>>>       particular case where NTP is used, these 32 bits provide the 32
>>>       least significant bits of a 64 bit NTP timestamp."
>>> 
>>> I found the above text a bit confusing about when including SCT-LOW. It
>>> says that also SCT-HIGH must be set. I didn't get that means multiple
>>> 32-bit entries until reading at the end. Maybe the following text should
>>> be moved earlier in the section?
>>> 
>>> "  Several "time value" fields MAY be present in a given EXT_TIME Header
>>>    Extension, as specified in the "Use-field".  When several "time
>>>    value" fields are present, they MUST appear in the order specified by
>>>    the associated flag position in the "Use-field": first SCT-High (if
>>>    present), then SCT-Low (if present), then ERT (if present), then SLC
>>>    (if present).  Receivers SHOULD ignore additional fields within the
>>>    EXT_TIME Header Extension which they do not support."
>>> 
>> 
>> Ok, I'll move that para to immediately below the figure.
>> 
>>> 7. Section 6.1:
>>> 
>>> "  The session description could be in a form such as SDP as defined in
>>>    [RFC2327], or XML metadata as defined in [RFC3023], or HTTP/Mime
>>>    headers as defined in [RFC2616], etc."
>>> 
>>> Aren't there more concreate examples of XML formats for this usage then
>>> referencing RFC 3023?
>> 
>> In due course there may be a DVB specification which includes this
>> information in the DVB XML metadata, but I don't think that is available
>> yet. I agree that arbitrarily referencing generic data format specifications
>> has little value, though. So I propose to change this text to:
>> 
>> "The session description could be in a form such as SDP as defined in
>> RFC4566, or another format appropriate to a particular application"
>> 
>> 
>>> 8. Section 7, and possible in other places as well. This document talks
>>> about authentication mechanism as very needed. But you haven't included
>>> any references to the ones we actually have been discussing or even
>>> developed for usage with RMT. I think some up to date references here
>>> would be good. Maybe even recommendations?
>>> 
>>> 9. Section 8.
>>> 
>>> Please update the reference to TESLA to the TESLA based mechanism for RMT.
>>> 
>> 
>> See above.
>> 
>>> 10. Section 9.1:
>>> In RFC 5226 that obsoletes RFC 2434 the IETF consensus policy does not
>>> exist, instead the corresponding one is IETF Review.
>>> 
>> 
>> Ok.
>> 
>>> When submitting an updated draft, please remember RFC 5378 and the
>>> issues with it.
>> 
>> I believe the bleeding-edge version of xml2rfc will take care of this for
>> me.
>> 
>>> Cheers
>>> 
>>> Magnus Westerlund
>>> 
>>> IETF Transport Area Director & TSVWG Chair
>>> ----------------------------------------------------------------------
>>> Multimedia Technologies, Ericsson Research EAB/TVM
>>> ----------------------------------------------------------------------
>>> Ericsson AB                | Phone  [phone]
>>> Färögatan 6                | Mobile [phone]
>>> SE-164 80 Stockholm, Sweden| mailto: [e-mail]
>>> ----------------------------------------------------------------------
>> 
>> _______________________________________________
>> Rmt mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/rmt