Re: Rmt Digest, Vol 65, Issue 2

Some comments at the end below. (Start with *** (MGL).)


On 12/8/09 12:00 PM, "[email protected]" <[email protected]> wrote:

If you have received this digest without all the individual message
attachments you will need to update your digest options in your list
subscription.  To do so, go to

https://www.ietf.org/mailman/listinfo/rmt

Click the 'Unsubscribe or edit options' button, log in, and set "Get
MIME or Plain Text Digests?" to MIME.  You can set this option
globally for all the list digests you receive at this point.



Send Rmt mailing list submissions to
        [email protected]

To subscribe or unsubscribe via the World Wide Web, visit
        https://www.ietf.org/mailman/listinfo/rmt
or, via email, send a message with subject or body 'help' to
        [email protected]

You can reach the person managing the list at
        [email protected]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Rmt digest..."


Today's Topics:

   1. Re: AD evaluation comments on draft-ietf-rmt-flute-revised-06
      (Magnus Westerlund)


----------------------------------------------------------------------

Message: 1
Date: Tue, 08 Dec 2009 10:54:53 +0100
From: Magnus Westerlund <[email protected]>
Subject: Re: [Rmt] AD evaluation comments on
        draft-ietf-rmt-flute-revised-06
To: Vincent Roca <[email protected]>
Cc: [email protected], "[email protected]" <[email protected]>
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1

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.

*** (MGL) To clarify, what I suggest is to say that "... a FLUTE sender SHOULD assume receivers will not receive all packets pertaining to FDT instances, i.e., it is RECOMMENDED that FDT instances be managed in such a way that a receiver will be able to recover at least one FDT instance describing a file delivered within the FLUTE session with as much or greater reliability as the receiver is able to receive enough packets containing encoding symbols for the file to recover the file.  As an example, one way to satisfy this recommendation is to repeat FDT instances describing the file often enough. As another example, another way to satisfy this recommendation is to use an FEC code for an FDT instance describing the file and send encoding symbols for the FDT instance often enough."  BTW, I didn't understand what it meant to be "self-sufficient", nor what it meant to "repeat all FDT instances that complement each other at a given moment".  I'm guessing that "self-sufficient" means an FDT instance that describes all files being delivered at that time?  And, "repeat all FDT instances that complement each other at a given moment" means something like repeat all FDT instances that are relevant to a particular receiver at a given moment?  (But I'm not sure if complement is used here in the same sense as how complement is used elsewhere in the draft, and it seems like it is different as the other sense of complement doesn't make sense here.)  Anyway, perhaps these examples could be fleshed out a bit?

Cheers

Magnus Westerlund

IETF Transport Area Director
----------------------------------------------------------------------
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 protected]
----------------------------------------------------------------------


------------------------------

_______________________________________________
Rmt mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rmt


End of Rmt Digest, Vol 65, Issue 2
**********************************

_______________________________________________
Rmt mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rmt