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

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

All,

I am planning to submit the new ALC and LCT drafts later today, so if you have comments, today would be good.

...Mark


On 7/8/09 4:31 PM, "Mark Watson" <[e-mail]> wrote:

All,

I am just about to submit updated ALC and LCT drafts, but I need to check where we are. Below is where this thread stopped on the technical side and branched into the WEBRC discussion (more on that later...)

As I understand the outcomes (by which I mean proposals left un-objected-to in the thread) are:

 *   refer also to draft-ietf-rmt-simple-auth-for-alc-norm for a possible authentication solution
 *   packets which fail authentication may contribute to congestion control (if this happens before authentication) but should otherwise be silently discarded (and in particular if you receive a lot of them it should not cause you to leave the session)
 *   rename PSI bits to avoid confusion with LCT A and B bits
 *   relax requirement to use EXT_AUTH for authentication (in particular IPSec does not do this)
 *   some editorial comments from Vincent

Additionally, the last word on mandating support for a security mechanism was Vincent's proposal to mandate draft-ietf-rmt-simple-auth-for-alc-norm, but since this is a new and substantial proposal in a long email trail I haven't implemented it yet. We need to choose:
(a) SHOULD strength requirements for security only (current status)
(b) mandate support for IPSec approach
(c) mandate support for draft-ietf-rmt-simple-auth-for-alc-norm

Regarding mandating support for the no-code FEC Scheme, it seems I said below that I did not have a big objection but then went on to state an objection anyway (you could conclude it was only a small one ;-). Noone has commented on this so for the moment I have left it unspecified.

Regarding allowing packets which fail authentication to affect congestion control, I suggested below that receivers might change this behaviour if they receive 'a lot' of fake packets (choosing instead to make the CC less responsive rather then be acting on fake packets). Again noone has commented so I will make a more explicit proposal: add the following text to the end of Section 4.4: "It is RECOMMENDED that if receivers detect multiple packets which fail authentication checks within a session then the above procedure should be modified for this session so that Step 3 is delayed until after the authentication check and only performed if the check succeeds."

Finally, regarding WEBRC, this protocol was fully implemented and tested around the time it was proposed/published and we believe it works very well. Since we are only at Proposed Standard stage, I think we should go ahead. BCP9 says 'Usually, neither implementation nor operational experience is required for the designation of a specification as a Proposed Standard.' Admittedly, it does go on to say 'The IESG may require implementation and/or operational experience prior to granting Proposed Standard status to a specification that materially affects the core Internet protocols or that specifies behavior that may have significant operational impact on the Internet.' so ultimately this is an IESG decision, bearing in mind though that multicast is not widely supported on the Internet.

...Mark

...Mark

On 5/15/09 9:36 AM, "Mark Watson" <[e-mail]> wrote:

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.