Comments below, marked >>>. I think (though I need my co-authors to agree of course) that a draft with these revisions (and any others we need) will be appropriate following any other IETF LC comments. -- Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 | Fax: +44 1245 242124 chris.dearlove@xxxxxxxxxxxxxx | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: ietf-bounces@xxxxxxxx [mailto:ietf-bounces@xxxxxxxx] On Behalf Of Russ Housley Sent: 14 June 2013 21:24 To: IETF Cc: IETF Gen-ART; manet@xxxxxxxx Subject: Gen-ART Review of draft-ietf-manet-rfc6622-bis-02 ----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages. -------------------------------------------------------- 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 resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-manet-rfc6622-bis-02 Reviewer: Russ Housley Review Date: 2013-06-15 IETF LC End Date: 2013-06-27 IESG Telechat date: Unknown Summary: The document is almost ready for publication as a standards track RFC. I raise one major concern, and once it is resolved, the document will be ready. Major Concern: In Section 12.2.3, is there any difference in processing when the source IP address is IPv4 as opposed to IPv6? Obviously, the two have a different length. Off the top of my head I cannot find a way for an attacker to exploit one party using IPv4 in the ICV calculation and the other party using IPv6. Since the IPv6 address is 12 octets longer than the IPv4 address, there may be some opportunity for an attacker. Anyway, concerns like this are usually thwarted by including the length of the overall hash function input as the first octet or two of the value-to-be-hashed. Such a value does not need to be transmitted. Each party knows how many octets it passed to the hash function. >>> As it happens, this value is present in the packet header, but not in the message header, and we do not want to introduce a difference between them. In addition, being after the address might not work. >>> Like you, I can't see how to exploit and still maintain a legal structure following, but attackers can be very resourceful. and I don't see that this can be guaranteed. >>> Thus, this appears a good suggestion, with minimal computational overhead and no over the air overhead. Minor Concerns: I find Section 1.1 a bit confusing. I think it should start by saying that RFC 6622 defined two ICV TLV extension types (0 and 1). This document repeats those definitions and adds a third ICV TLV extension type (2). >>> OK. Section 5 says: An ICV TLV with type extension = 2 specifies a modified version of this definition. This is unclear. I believe that an ICV TLV with type extension = 2 is an update to ICV TLV with type extension = 1. It would be good to introduce the need for this update. I suggest: An ICV TLV with type extension = 2 is the same as an ICV TLV with type extension = 1, except that the integrity protection also covers the source address of the IP datagram carrying the packet, message, or address block. >>> Might tweak that a little, but OK. If you accept this suggestion, the following paragraph should also be revised. I suggest: Specifically, with type extension = 1 or type extension = 2, the <value> field contains the result of combining a cryptographic function and a hash function. The <value> field contains multiple sub-fields indicating which hash function and cryptographic function have been used as specified in Section 12. >>> Essentially moving detail from this paragraph to previous one. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ********************************************************************