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

[Magnus Westerlund <[e-mail]>]

Vincent Roca skrev:
> 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).

Yes, I think that is a good suggestion.

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

Vincent, I think your recommendations are good. However, also I am
lacking information about thus. However, I don't see that a
recommendation will create any serious issue for our users. They can
either accept it or explain why their usage should ignore the
recommendation.

Cheers

Magnus Westerlund

IETF Transport Area Director
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  [phone]
Färögatan 6                | Mobile [phone]
SE-164 80 Stockholm, Sweden| mailto: [e-mail]
----------------------------------------------------------------------