In your previous mail you wrote:
> > 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.
=> 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.
> > - 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?
=> 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 (:-)!
> 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]).
=> fine!
> > - 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 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.
> 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".
=> 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
francis.dup...@fdupont.fr
PS: I still wait for a new version.
_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
