[Gen-art] RE: Gen art review: draft-maino-fcsp-02.txt

[[e-mail]]

Elwyn,

Thanks for the review.  I don't think any significant changes are
needed:

> s4.1, last para: It might be good to cite 
> RFC2402RFC2406/draft-ietf-ipsec-esp-ah-algorithms-02.txt to cover all 
> the 'standard' algorithms rather than one specific algorithm 
> (RFC3602).

Not exactly.  RFC 3602 is correctly cited as an example in a sentence
saying that all algorithms for ESP are applicable.  It would be wrong
to cite anything related to AH, as there will be no support for any form
of AH in Fibre Channel.  A reference to the ESP RFC would be reasonable
to add.

The recommended and required algorithms for ESP in FC will be specified
in the FC-SP standard, and a number of existing IPsec algorithms are
likely to be required.  OTOH, it would be wrong to reference even the
ESP portion of the algorithms draft, as the FC algorithm requirements
are likely to be different (e.g., FC has a strong interest in AES-GCM).

> s4.2, last para: Nothing is said here about alternative future integrity 
> algorithms. Given recent discussion about attacks on MD5 and SHA1, and 
> general views about the need for security algorithms to be replaceable 
> limiting integrity protection to just two current algorithms is not a 
> good idea.

The "attacks on MD5 and SHA1" do not work on the keyed HMAC-based
integrity algorithms used here.  The integrity algorithms are replaceable,
as the SAID functions similarly to an IPsec SPI in selecting the algorithms
to apply and I could see adding a sentence to say that.  In fact one of
the reasons for having IANA allocate values for these algorithms is
to make it easier to replace them, and I could see adding a sentence
to say that.

The suggested reclassifications of references are reasonable, although
the IANA allocations that result from this draft becoming an RFC are
necessary to complete the FC-SP standard.

The editorial suggestions can be handled between the RFC Editor and
Authors 48 hours.

Thanks,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
[phone]             FAX: [phone]
[e-mail]        Mobile: [phone]
----------------------------------------------------
> -----Original Message-----
> From: Elwyn Davies [mailto:[e-mail]] 
> Sent: Tuesday, September 27, 2005 4:29 AM
> To: [e-mail]; Mary Barnes; Russ Hously; 
> [e-mail]; Black, David
> Subject: Gen art review: draft-maino-fcsp-02.txt
> 
> Background for those on the CC list, who may be unaware of GenART:
> GenART is the Area Review Team for the General Area of the IETF.  We
> advise the General Area Director (i.e. the IETF/IESG chair) by providing
> more in depth reviews than he could do himself of documents that come up
> for final decision in IESG telechat.  I was selected as the GenART
> member to review this document.  Below is my review, which was written
> specifically with an eye to the GenART process, but since I believe that
> it will be useful to have these comments more widely distributed, others
> outside the GenART group are being copied.
> 
> Document: draft-maino-fcsp-02.txt
> Intended Status: Informational (individual submission via AD)
> Shepherding AD: Russ Housley
> Review Trigger: IESG Telechat 29/9/05
> 
> Summary:
> An excellent document IMO - easy to read and with excellent balance 
> between motivation, explanation and technical detail! Kudos to the 
> authors.  Given this document is informing the IETF about what Fibre 
> Channel is doing, there is no obligation to fix up the couple of issues 
> relating to extensibility/future proofing but given IETF experience, it 
> might be appropriate to consider remedying them.  There are also some 
> editorial nits.
> 
> Review:
> Generally an excellent document.  Given recent IETF experience and the 
> general degradation over time of the value of security algorithms, I 
> think it would be appropriate to provide very explicitly for algorithm 
> replacement, especially as regards the integrity algrithms which are (as 
> I read the document) currently fixed.  The first two issues give the 
> details:
> 
> s4.1, last para: It might be good to cite 
> RFC2402RFC2406/draft-ietf-ipsec-esp-ah-algorithms-02.txt to cover all 
> the 'standard' algorithms rather than one specific algorithm (RFC3602).  
> Also it would probably be good to make it crystal clear that any future 
> transforms that might be invented to go with ESP would be available for 
> use for Fibre Channel.
> 
> s4.2, last para: Nothing is said here about alternative future integrity 
> algorithms.  Given recent discussion about attacks on MD5 and SHA1, and 
> general views about the need for security algorithms to be replaceable 
> limiting integrity protection to just two current algorithms is not a 
> good idea.
> 
> s8.1: I would consider refs FC-FS, FC-GS and FC-SP as normative.
> 
> s8.2: I think RFCs 2625, 3643 and 3821 are informative as the various 
> payloads are not IP encapsulated.
> 
> Editorial nits:
> s4, para 3: s/Preambol/Preamble/
> 
> s4, last para: s/Security Association for/Security Associations for/
> 
> s4.1: Fields are 'normalized before computation': presumably this is 
> clear to somebody skilled in the Fibre Channel arts but a ref to the 
> appropriate piece of specification or an inline description 
> would help 
> for the unenlightened.
> 
> s4.1, Figure 1: Technically the 'Auth' coverage should be 'Integrity' 
> coverage (and this would match with the corresponding figure in 
> draft-ietf-ipsec-esp-v3-10.txt).
> 
>  s5.2, para 2: s/protocol ID/protocol IDs/
> 
> s5.4, para 5 (next to last): s/he function/the function/
> 
> s5.4, last para: s/Associaton/Association/
> 
> s6, para 2: s/then there are no theoretical limitations/so that there 
> are no a priori limitations/ (the previous phrase gives the 
> theoretical 
> limit of 4GB!)
> 
> s8.2: Should be entitled Normative References
> 

_______________________________________________
Gen-art mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/gen-art