Re: [Rmt] AD comments on draft-ietf-rmt-pi-alc-revised-06

["Watson, Mark" <[e-mail]>]

Hi Magnus,

Response and proposed actions inline below.

Thanks!

...Mark


On 4/17/09 7:08 AM, "Magnus Westerlund" <[e-mail]>
wrote:

> Hi,
> 
> I have reviewed the ALC PI and have some comments.
> 
> 1. If one compare this one with the experimental one they are very
> similar. At least my expectation would be that a bit more details are
> actually nailed down on how one should do them to achieve interoperable
> implementations. For example the choice of congestion control algorithm.
> I think we only have one that we can really use to satisfy the intended
> usage of large scale sessions. Why isn't this a required to implement
> feature?
> 
> The same thing can be said about normative to implement security
> features. Yes, here there are choices, but still specify one required to
> implement should be possible. If you have observant the NORM PI got this
> comment from the SECdir reviewer. And I think he was right, we should be
> clear on these.
> 
> A question is if we need to specify one mandatory to implement FEC
> encoding?
> 
> In general I am not against the flexibility the protocol allows for.
> However, it should be clear what you do need to implement for a
> base-line implementation.
> 

If I understand the WG discussion correctly, we should mandate the support
of WEBRC for Congestion Control. I propose to replace the first sentence of
section 2.2 (Multiple Rate Congestion Control Building Block) with

"At a minimum, implementations of ALC MUST support [RFC3738]."

And reword the following paragraphs appropriately.

For security, as with NORM, we have text defining 'Baseline secure ALC
operation'. Do you think we should mandate support for this ?

> 2. Section 2, third paragraph:
> "This
>    specification defines ALC as payload of the UDP transport protocol
>    [RFC0768] that supports IP multicast delivery of packets.  Future
>    versions of this specification, or companion documents may extend ALC
>    to use the IP network layer service directly.  ALC could be used as
>    the basis for designing a protocol that uses a different underlying
>    network service such as unicast UDP, but the design of such a
>    protocol is outside the scope of this document."
> 
> This type of text seems out of place. You are not any longer describing
> a experimental protocol. State what is, not what could have been. Also
> the ALC PI would not work from a congestion control side over unicast IP.

Agreed.

> 
> 3. I am also disappointed that the ID nits hasn't been taking care of:
> 
...
> Yes, there is a difference between the draft submission check and the
> full checks that the tools page provide.

Indeed - something I learned *after* submission of the previous draft ;-)

> At publication request time I
> do expect the draft be without real nits.
> 
> 4. There are more references that are not updated. Cases where mechanism
> are available in IETF draft, like the TESLA solution. Which would impact
> the reference for example in Section 5, third paragraph.
> 

I added the TESLA for ALC/NORM draft as a reference and reference from that
paragraph. Are there others that you saw other than those found by idnits ?

> 5. Section 4.4:
> 
> "If immediate checking is possible and if the packet
>    fails the check then the receiver MUST discard the packet and reduce
>    its reception rate to a minimum before continuing to regulate its
>    reception rate using the multiple rate congestion control."
> 
> Isn't the above instruction about reducing the rate based on packets
> that fails authentication checks resulting in another DoS vector on the
> receiver. If the only thing I need to do to keep the receiver at minimum
> reception rate is to send the occasional packet that fails the checks
> that seems extremely cheap. Can you please elaborate what the thoughts
> where on this?
> 

Agreed. The correct response to a packet authentication failure should be a
silent discard. I propose to replace this paragraph with the following

"If immediate checking is possible and if the packet fails the check then
the receiver MUST silently discard the packet."

The following paragraph repeats this problem and so I propose to replace
that with:

"Some packet authentication schemes such as TESLA
[ietf-msec-tesla-for-alc-norm] do not allow an immediate authenticity check.
In this case the receiver SHOULD check the authenticity of a packet as soon
as possible, and if the packet fails the check then it MUST be silently
discarded before step (5) above."

> So in conclusion I think this document needs a work over and some
> nailing down on what is mandatory to implement. I am expecting a revised ID.
> 
> 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
>