Subject: [RTG-DIR] RtgDir review: draft-ietf-ospf-auth-trailer-ospfv3-05.txt

From: Alia Atlas <[email-masked]>
Date: Mon, 15 Aug 2011 13:07:18 -0400

Hello,

I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://www.ietf.org/iesg/directorate/routing.html

Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft.

Document: draft-ietf-ospf-auth-trailer-ospfv3-05.txt
Reviewer: Alia Atlas
Review Date: August 15, 2011
IETF LC End Date: August 16, 2011
Intended Status: Standards Track

Summary:

This document is basically ready for publication, but has nits that should be considered prior to publication.

Comments:

I found this draft to be very well written and carefully addresses details and transitions.  The technology is a straightforward extension of work done for OSPFv2 to apply to OSPFv3 with the added benefit of protecting against replay attacks.

Major Issues:

Minor Issues:

Nits:

1) In Sec 4.1, for Cryptographic Sequence Number, additional description indicating behavior when the value wraps would be useful.  If that is never expected, that is also useful to state.  The phrase "strictly increasing" is not sufficiently clear to me.

2) In Sec 1, 3rd paragraph, last sentence
 /s/platforms or it/platforms or with it/

3) In Sec 3, 3rd paragraph under Security Association Identifier (SA ID), first sentence
/s/The sender based on/The sender, based on/
/s/OSPFV3/OSPFv3/

4) Last paragraph on p. 13:
" If the cryptographic sequence number in the AT is less than or equal
   to the last sequence number received from the neighbor, the OSPFv3
   packet MUST be dropped."
Perhaps change received to "successfully received" just to clarify that only packets which have
passed the authentication check will have their sequence number used to update the last sequence number.

5) Sec 8.1:  Shouldn't OSPFv3 [RFC5340] be a normative reference rather than informative.

---

From: Acee Lindem <[email-masked]>
Date: Wed, 17 Aug 2011 11:17:21 -0400

Hi Alia,

Thanks much for the thorough review. We have some comments from Sam as well. We will incorporate your updates once we decide what to do with his comments which are mostly based on the presumption of a global crypto table infrastructure (which was only recently made a KARP WG document). See inline. 

On Aug 15, 2011, at 1:07 PM, Alia Atlas wrote:

> 1) In Sec 4.1, for Cryptographic Sequence Number, additional description indicating behavior when the value wraps would be useful.  

We will add this. I admit that the behavior is implied based on the discussion of the upper word in the sequence number. 

> If that is never expected, that is also useful to state.  The phrase "strictly increasing" is not sufficiently clear to me.

This is as opposed to the current requirement that the sequence number is monotonically increasing. Would adding, ",i.e., greater than the previously received sequence number," suffice? The term "strictly increasing" is used in this Wiki: http://en.wikipedia.org/wiki/Monotonic_function

> /s/platforms or it/platforms or with it/

Will update. 

> /s/The sender based on/The sender, based on/

Good catch. 

> passed the authentication check will have their sequence number used to update the last sequence number.

Good point. 

> 5) Sec 8.1:  Shouldn't OSPFv3 [RFC5340] be a normative reference rather than informative.

I agree. 

Thanks,
Acee

---

From: Alia Atlas <[email-masked]>
Date: Wed, 17 Aug 2011 20:48:36 -0400

Hi Acee,

On Wed, Aug 17, 2011 at 11:17 AM, Acee Lindem <[email-masked]>wrote:

> Hi Alia,
>
> Thanks much for the thorough review. We have some comments from Sam as
> well. We will incorporate your updates once we decide what to do with his
> comments which are mostly based on the presumption of a global crypto table
> infrastructure (which was only recently made a KARP WG document). See
> inline.
>

Sam's comments are based on a wider experience of key management and
handling.  Certainly, I don't think that OSPFv3 should have worse key
management than OSPFv2 does.

> > 1) In Sec 4.1, for Cryptographic Sequence Number, additional description
> indicating behavior when the value wraps would be useful.
>
> We will add this. I admit that the behavior is implied based on the
> discussion of the upper word in the sequence number.
>
> > If that is never expected, that is also useful to state.  The phrase
> "strictly increasing" is not sufficiently clear to me.
>
> This is as opposed to the current requirement that the sequence number is
> monotonically increasing. Would adding, ",i.e., greater than the previously
> received sequence number," suffice? The term "strictly increasing" is used
> in this Wiki: http://en.wikipedia.org/wiki/Monotonic_function
>

Strictly increasing is fine and clear until one gets to the question of what
happens when the number needs to wrap.  That's my only concern.

Alia