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

From: "Watson, Mark" <[email-masked]>
Date: Tue, 12 May 2009 17:19:28 -0700

Hi Magnus,

Response and proposed actions inline below.

Thanks!

...Mark

On 4/17/09 7:08 AM, "Magnus Westerlund" <[email-masked]>
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  +46 10 7148287
> Färögatan 6                | Mobile +46 73 0949079
> SE-164 80 Stockholm, Sweden| mailto: [email-masked]
> ----------------------------------------------------------------------
> _______________________________________________
> Rmt mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rmt
>

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 13 May 2009 11:41:21 +0200

Hi Mark and the WG,

I think most proposed changes looks fine. I comment on the question
below. And we do need WG input into one question.

> operation'. Do you think we should mandate support for this ?

Yes, I think so. But I definitely would like to get WG input into this
question.

> paragraph. Are there others that you saw other than those found by idnits ?

No, not what I can remember.

Cheers

Magnus Westerlund

---

From: Vincent Roca <[email-masked]>
Date: Fri, 15 May 2009 15:40:49 +0200

Hello Mark, Magnus and others,

A few comments concerning this I-D and the discussion.
Regards,

   Vincent

>> A question is if we need to specify one mandatory to implement FEC

Current DVB-H specifications have identified a single mandatory
to support FEC scheme: NULL-FEC. I don't see any reason to do a
different choice. In any case yes, we should mandate its support.

> Yes, I think so. But I definitely would like to get WG input into this

I don't really understand what "mandate" means in this context.
I see several options, which one is appropriate?

1- all ALC sessions MUST use the IPsec configuration of section 5.1.1
2- for any insecure ALC session, there MUST be a parallel ALC session
   secured with the IPsec configuration of section 5.1.1, so that a
   receiver can choose what version he wants
3- for any ALC implementation, the host on which this ALC server or
   client runs MUST be able to use the IPsec configuration of
   section 5.1.1

I think option 3- is the right one. However since the ALC and IPsec
building blocks belong to different layers, it does not impose anything
to ALC developers (as a developer, I'm happy ;-)). And it does not say
anything about its actual use...

Additionally, is such a requirement compatible with current DVB-*
deployments? I'm not sure, unless we restrict the target and say
that such a requirement is specific to "Internet" use-cases...

More fundamentally, I have two comments:

First of all, do we agree that packet source authentication/packet
integrity is the most fundamental security service that is required
by ALC? It means we don't need to mandate confidentiality (even if
it's often desired).

Then, what about the solution consisting in mandating the simplest
technical solution, even if it does not fulfill all possible use-cases?
If this is the case, then the "group MAC" scheme proposed in the
simple-auth-for-alc-norm I-D is a good choice.
But here also, it's not compatible with current DVB-* deployments
unless we restrict the target to "Internet" use-cases... It's what
I'd recommend here today.

> paragraph.

The ALC I-D should also refer to draft-ietf-rmt-simple-auth-for-alc-norm
in addition to draft-ietf-msec-tesla-for-alc-norm, IMHO. Its goal is
exactly what we are discussing here.

> discarded before step (5) above."

There is a coherency problem WRT draft-ietf-rmt-bb-lct-revised-09.txt
where it is said (section 5.2.1):
                 Some packet authentication schemes impose a delay of
                 several seconds between when a packet is received and
                 when the packet is fully authenticated.  Any congestion
                 control related action that is appropriate MUST NOT be
                 postponed by any such full packet authentication.
The two versions are compatible, but they don't focus on the same point.
In ALC => discard TESLA packets that fail the check
In LCT => don't delay congestion control, even if the packet is not yet
          checked by TESLA (i.e., protect the network, even if it creates
          a potential DoS)
I suggest to use the same paragraph in both cases.

It's also in line with draft-ietf-msec-tesla-for-alc-norm-07 (section 4.3):
- perform congestion control ASAP, even if the packet is not authenticated
- discard silently any packet that fails the authentication test

Additional comments (sorry if they arrive a bit late...)
--------------------------------------------------------

** Fig 1, PSI bits:
It turns out that the PSI bits are called A and B, just like the
LCT A (close session) and B (close object) flags. Admittedly, these
are PSI bits, but it can be a little bit confusing if we omit "PSI"
as in Fig. 1. I suggest to call them differently (e.g., PSI1 and PSI2).

** section 4.3: It is said:
   It is RECOMMENDED that packet authentication be used.  If packet
   authentication is used then the Header Extensions described in
   Section 4.2 MUST be used to carry the authentication.
Well, this only applies if an ALC-level authentication scheme is used.
EXT_AUTH is useless in case of IPsec!

** section 4.4: It is said:
   The receiver MUST be able to discard,
   forward, store or process the other headers and the packet payload.
I don't understand what "forward" means here. Probably to the upper layer
or a processing unit? I'd remove it.

** section 4.4, item 1: It is said:
       If multiple packets are received that cannot be parsed then
       the receiver SHOULD leave the session.
Same kind of remark as that of Magnus: mounting a DoS is trivial since it
is sufficient to send a few packets with random content (since item 1
happens BEFORE ALC-level authentication). If IPsec is used, of course this
does not apply.
I suggest however to "silently discard".

Same remark for item 2 where it is said:
       If multiple packets are received with non-matching
       (sender IP address, TSI) values then the receiver SHOULD leave
       the session.

** Section 5, second paragraph: It is said:
   Because of the use of FEC, ALC is especially vulnerable to denial-
   of-service attacks by attackers that try to send forged packets to
   the session...
Though I agree that the use of FEC encoding *amplifies* the problem,
the problems remains with NULL-FEC. A single forged source packet can
corrupt the whole object too.

** Section 5, 4th paragraph: It is said:
   ...to ensure that each received packet is an
   authentic and uncorrupted packet containing FEC data for the object
   arriving from the specified sender.
I'd remove "FEC data" since it is rather ambiguous to me.

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 15 May 2009 16:22:33 +0200

Hi Vincent,

See inline.

> anything about its actual use...

I mean 3, mandatory to implement.

> that such a requirement is specific to "Internet" use-cases...

What IETF puts in its standards track documents are after all what we
think is required for secure and functional operation in most network
environments. There will always be cases where one security solution can
be replaced by another for specific deployments.

> I'd recommend here today.

I definitely would like to see others opinions about this.

Cheers

Magnus Westerlund

---

From: "Watson, Mark" <[email-masked]>
Date: Fri, 15 May 2009 09:36:53 -0700

HI Vincent,

Thanks for the detailed comments. I will implement these. I have a yet-to-be-submitted update to LCT as well, so we can align the packet authentication failure text as you suggest.

The problem of the interaction with congestion control in the presence of forged packets which are only detected some time later seems a difficult one: either you delay congestion response until the packet is authenticated (which makes the congestion control less responsive) or you risk acting on false information and so open a DoS attack. In practice perhaps one should follow the latter approach until a packet with a failed integrity check is detected after which you should follow the former ? Then you hope that the effect of the attack becomes uninteresting to an attacker (security people ROFL here). Maybe there are better 'defensive' approaches.

I do not have a big objection to mandating support for no-code, but I think it deserves a little consideration: why would we do this ? Usually one mandates support for some minimum common functionality so that you can be sure that otherwise uncoordinated end hosts can always negotiate some way to interoperate. But we have no negotiation in a multicast context.

The sender of data over ALC will likely want to choose a single FEC code: if they advertise several sessions using different codes then they will end up sending data multiple times for different subsets of the audience, undermining the point of using multicast in the first place. So in practice the operator of an ALC sender needs to coordinate receivers somehow, for example they might provide or recommend suitable client software for their service rather than saying that end users can use any off-the-shelf ALC client they find (as is the case for unicast protocols such as HTTP).

The absence of a mandatory FEC code advertises this situation to users of the specification. Mandating No-Code perhaps gives the false impression that senders can effectively take advantage of some 'minimum level of interoperability': that all clients will be able to receive their sessions and that those with FEC support will just get better performance. This is not the case unless they provide duplicate sessions with different codes, which has a big cost.

...Mark

On 5/15/09 6:40 AM, "Vincent Roca" <[email-masked]> wrote:

   Vincent

** Fig 1, PSI bits: