Re: [Rmt] AD evaluation comments on draft-ietf-rmt-flute-revised-06

[Vincent Roca <[e-mail]>]

Magnus,

I've started going through your comments. I haven't finished yet, but
I'd like to see opinions about the following two topics:


> >> >> 2. I have basically the same comment on this document as on
> >> >> ALC PI about mandatory to implement security solutions.
> >> >>
> > >
> > > [Toni] Unfortunately I have not followed that closely the review on ALC. Could you please state the needed change you want to see in FLUTE RFC?
>
> Okay, the general issue comes from BCP 61 (RFC 3365) and I think the
> sentence from the end of section 6 is the most relevant:
>
>    The solution is that we MUST implement strong security in all
>    protocols to provide for the all too frequent day when the protocol
>    comes into widespread use in the global Internet.
>
> To achieve this and have interoperability also in the strong security
> mechanism the ground rule is to mandate implementation of at least one
> mechanism, cipher suite, etc to achieve that interoperability.
>
> The current security consideration section does a great job of
> discussing the threats and possible solution. But it doesn't mandate
> which solutions MUST be implemented.
>
> So the question to you and the WG is can we do this for FLUTE? I know
> this is not straight forward and certain deployments has different needs
> and use of security.

[VR] Since FLUTE relies on ALC/LCT, and since ALC has a "MANDATORY to
implement" requirement for IPsec (just like NORM), I think the natural
answer is "do what ALC mandates".
I'll kept the security risk analysis almost as such and will add a new
section to clarify this.

However it should be noted that ALC (NORM as well) restricts the use of
IPsec to the case of SSM. There is no mandatory to implement solution
for the case of ASM. Since ALC only considers the case of a single sender,
there's a good match with SSM. So I suggest to leave it like that (and it
didn't prevent NORM to be published as an RFC).


> >> >> 6. Section 3.4.1:
> >> >>   Mandatory receiver behavior for handling FDT Instance
> >> >>   ID wraparound and other special situations (for example, missing FDT
> >> >>   Instance IDs resulting in larger increments than one) is outside the
> >> >>   scope of this specification and left to individual
> >> >> implementations of
> >> >>   FLUTE.
> >> >>
> >> >> Why isn't this specified. Seem to be important for interoperable usage.
> >> >> Seems to be a fine thing to gloss over in an experimental, but
> >> >> not in a proposed standard.
> >> >>
> > >
> > > [Toni] The text states that what actions the special situation causes in the receiver is up to receiver. In a same way your web browser will typically show a different error message than my trying to access http://ww.w3.org. I see one valid
implementation trying to recover from situation by staying longer in the session and trying to deduce what happened. Meanwhile I see another implementation possibly using out of band methods (if available) for the same. In other words, error recovery or
concealment or similar is not in the scope of the spec.
>
> Hmm, I will let it slide. Let see if anyone else in IESG bites on this,
> clearly not impossible. As it from my perspective looks like where error
> conditions could be avoided by specifying the correct behavior.

[VR] I agree with Toni W.R.T. the problem of FDT Instance ID wraparound
when the two FDT Instances are non expired. It's clearly an erroneous
situation and how to address it is out-of-scope.

There's just an (easy to fix) issue in sections 3.1 and 3.3 that say:
     "Each File Delivery Table Instance is uniquely
      identified by an FDT Instance ID."
which contradicts the possibility of wraparound. I think that saying:
     "Each non-expired..."
solves it.


Now I don't agree with Toni W.R.T. the case of missing FDT Instance ID
(or IDs). IMHO this is not a special situation but a *common situation*.
That's typically what terminals with intermittent connections experience.
I suggest to make the support of this situation MANDATORY.

There are implications here, since FDT Instance management is rather
flexible, see Section 3.2:
  "Any FDT Instance can be equal to, a subset of, a
   superset of, or complement any other FDT Instance.  A certain FDT
   Instance may be repeated several times during a session, even after
   subsequent FDT Instances (with higher FDT Instance ID numbers) have
   been transmitted."
So if FDT Instances complement one another rather, there could be problems.
More precisely, imagine FDT Instance 1 describes objects A and B. Then
object C is added. If the sender chooses to describe only object C in
FDT Instance 2 (i.e. FDT Instances 1 and 2 complement each other) and
not to transmit FDT Instance 1 any more (it's authorized), a receiver that
missed FDT Instance 1 will not be able to process objects A and B, even
if he received enough encoding symbols for them.
Admitedly, it does not break the receiver, so it's safe, but it remains
largely sub-optimal.

So, IMHO, we should also clarify that a FLUTE sender SHOULD NOT assume
receivers will receive all FDT Instances, i.e. it is RECOMMENDED that
FDT Instances be managed in such a way to make the FLUTE session robust
in front of FDT Instance losses. One possibility is to use only
self-sufficient FDT Instances, another one is to repeat all FDT Instances
that complement each other at a given moment.

Having said that, I don't know if such a recommendation is in line with
current FLUTE deployment guidelines (e.g. in DVB-IPDC) ? Any comment or
additional piece of information here?


Regards,

  Vincent