Subject: Re: [Gen-art] (quick) review of draft-ietf-rmt-flute-revised-13.txt

From: Vincent Roca <[email-masked]>
Date: Mon, 12 Mar 2012 12:26:25 +0100

Hello Francis,

> I am the assigned Gen-ART reviewer for this draft. For background on
> Gen-ART, please see the FAQ at
> < http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
> 
> Please wait for direction from your document shepherd
> or AD before posting a new version of the draft.
> 
> Document: draft-ietf-rmt-flute-revised-13.txt
> Reviewer: Francis Dupont
> Review Date: 20120229
> IETF LC End Date: 20120224
> IESG Telechat date: 20120301
> 
> Summary: Almost Ready
> 
> Important note: due to last comments from the Last Call it seems
> there will be a -14 version...
> 
> Major issues: None
> 
> Minor issues: not a real one (it was inherited from RFC 5775) but
> in the security considerations there is nothing about IPsec/AH
> (BTW people who didn't implement it didn't implement the transport
> mode (for IPsec/ESP) too :-).

Yes, this is done deliberately. We do not mention IPsec/AH at all
and our minimum security requirements are aligned with that of
RFC 5775. For instance RFC5775, Section 5.1.1, says:

  "The ALC sender SHALL use an IPsec SA configured for Encapsulating
   Security Payload (ESP) protocol [RFC4303] operation with the option
   for data origination authentication enabled."

I think the situation is clear enough.

> Nits/editorial comments:
> - ToC page 3 and 9 page 36: Acknowledgements -> Acknowledgments

Done.

> - 1 page 6: please add a reference to RFC2357 (or make it an
>  explicit reference)

I don't understant. We already have a reference to that RFC in section 1, p6:
  "This specification contains part of the definitions necessary to
   fully specify a Reliable Multicast Transport protocol in accordance
   with [RFC2357]."
What is the point?

> - 1.1.3 page 7: I suggest to add the "diode" in the environment
>  where FLUTE can be used (diodes are more common than you can
>  believe :-)
> 
> - 3 page 9 (and other places): e.g. -> , e.g., and i.e. -> , i.e.,

Done.

> - 3.1 page 9: I'd like to get the type (e.g., integer) of fields,
>  for instance I have no idea of what a TSI really looks like.

I've clarified what a TSI looks like as follows:

NEW:
   One of the fields carried in the ALC/LCT header is the Transport
   Session Identifier (TSI), an integer carried in a field of size 16,
   32, or 48 bits (note that the TSI may be carried by other means in
   which case it is absent from the LCT header [RFC5651]).

> - 6 page 27: session ; -> session; and at the next line
>  session. -> session; (only the last item gets a dot)

Right. Done.

> - 7.2.2 page 30: this is the place I am surprised to not get
>  IPsec/AH [RFC4302] as an alternative to IPsec/ESP [RFC4303]
>  when integrity and sender authentication is wanted.

An interesting reference:
	"A Cryptographic Evaluation of IPsec"
	Niels Ferguson and Bruce Schneier
	http://www.schneier.com/paper-ipsec.pdf
Section 3.1:
	"Recommendation 2: Eliminate the AH protocol."

Another reference on the same topic:
	"Avoiding Authentication Header (AH)"
	draft-bhatia-ipsecme-avoiding-ah-00

I don't follow the IPSECME WG and therefore I cannot
say wether there is consensus or not on the topic.
However it seems to me it's not worth adding a reference
to AH. We can do without, using the functionalities already
provided in the "minimum security requirements".

> - 10 page 36:
>  52134 Herzogenrath, Germany ->
>  52134 Herzogenrath
>  Germany

Done.

> - Authors' Addresses page 45: US -> USA
>  (note: the Innovallee; is dubious too)

s/US/USA/: Done:
Concerning the Inovallée, I can't change our official postal address ;-)

> Regards
> 
> [email-masked]
> 
> PS: I expect to get the new version so to have more time
> to read (more) carefully the body of the document (i.e., 3 - 6).

Okay. Thanks Francis.

   Vincent

---

From: Francis Dupont <[email-masked]>
Date: Mon, 12 Mar 2012 21:54:35 +0100

>  I think the situation is clear enough.

=> yes: even I still like to get IPsec/AH I understand the mistake
(if it is a mistake) was done with the RFC 5775 so it is far too late.

>     fully specify a Reliable Multicast Transport protocol in accordance

=> I have in the .txt version:

   This specification contains part of the definitions necessary to
   fully specify a Reliable Multicast Transport protocol in accordance
   with RFC2357.
        ^^^^^^^

and it is the only occurrence of 2357. BTW I am fine of course with
your personal (?) version of the document (:-)!

>     which case it is absent from the LCT header [RFC5651]).

=> fine!

>  say whether there is consensus or not on the topic.

=> there is not and IMHO there won't be... AH will be withdrawn
because people are tired to explain how it can be used, not
because people are convinced it is useless.

>  provided in the "minimum security requirements".

=> this was addressed with the (previous) minor issue:
IPsec/AH is not in RFC 5775 so there is no reason it should be
in draft-ietf-rmt-flute-revised.

Thanks

PS: I still wait for a new version.