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

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

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" <[e-mail]> wrote:

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
>> encoding?

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.


>> For security, as with NORM, we have text defining 'Baseline secure ALC
>> 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.

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.


>>> 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.

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.


> 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."

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.