Subject: [Gen-art] Gen-ART review of draft-ietf-opsec-ip-security-05

From: "Vijay K. Gurbani" <[email-masked]>
Date: Mon, 03 Jan 2011 12:05:03 -0600

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-opsec-ip-security-05
Reviewer: Vijay K. Gurbani
Review Date: Jan-03-2011
IETF LC End Date: Dec-12-2010
IESG Telechat date: Unknown

Summary: This draft is ready as an Informational RFC.
Major issues: 0
Minor issues: 0
Nits/editorial comments: 9

Sorry for the late review, I note that this document is in
IESG evaluation state, so I suspect that one more revision
may be required.  If so, I hope the following feedback aids
in improving an already excellent document.

1) S3.3.2.2, page 14 --- please expand the acronym "RED" on first use.

2) S3.5.1, top of end of page 16 and top of page 17 --- "Linux (and
  Solaris) later set the IP Identification field on a per-IP address
  basis."  Which address --- source or destination?

3) S3.5.2.2, page 18 --- s/Packet loss is can be/Packet loss can be/

4) S3.6, underneath Figure 5 on page 20 ---
  s/In Figure 3, an attacker/In Figure 5, an attacker/

5) Same section, same page ---
  s/router that encounters that this/router to determine that this/

6) S3.7 --- when discussing the Fragment Offset, is it worth
  stating that the Fragment Offset is measured in units of 8 octets
  (thereby giving the magic number 65528 = 8191*8)?

7) S3.8.4, page 26, last bullet item at top of page ---
  s/Four hops away from D./Two hops away from D./

8) S4.1.1.3, page 51, last paragraph of that subsection ---
  Any references?

9) S4.1.1.4, page 52, first bullet item, first sentence ---
  what do you mean by "overlapping fragments"?  Maybe you meant,
  instead, "duplicate fragments"?

Thanks,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
Web:   http://ect.bell-labs.com/who/vkg/

---

From: Fernando Gont <[email-masked]>
Date: Mon, 03 Jan 2011 18:23:12 -0300

Hi, Vijay,

Thanks so much for your feedback! -- Please find my response inline...

> 1) S3.3.2.2, page 14 --- please expand the acronym "RED" on first use.

Will do.

>  basis."  Which address --- source or destination?

"destination" -- although "per-remote IP address" would probably be more
correct clearer here. Thoughts?

>  s/In Figure 3, an attacker/In Figure 5, an attacker/

Good grief! -- Will fix this one.

>  s/router that encounters that this/router to determine that this/

Yep, better. Will fix this. Thanks!

>  (thereby giving the magic number 65528 = 8191*8)?

This *is* mentioned in the first paragraph of Section 3.7, as follows:

---- cut here ----
   It indicates where in the original datagram payload
   the payload of the fragment belongs, and is measured in units of
   eight bytes.
---- cut here ----

So I assume no changes needed here?

>  s/Four hops away from D./Two hops away from D./

The original text is incorrect, but I should s/Four/Three/ (rather than
s/Four/Two/). -- Will fix this as I've indicated.

> 8) S4.1.1.3, page 51, last paragraph of that subsection ---

One possible example would be the ping 'o death. -- I will provide
references in the next rev of the document.

>  instead, "duplicate fragments"?

No, I did mean "overlapping fragments" -- i.e., fragments that contain a
portion of the same piece of original datagram (i.e., they overlap with
each other)

Thanks!

Kind regards,
-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Mon, 03 Jan 2011 16:03:57 -0600

> Thanks so much for your feedback! -- Please find my response inline...

Fernando: Please see inline on those comments that require
a follow-up from me.

> correct clearer here. Thoughts?

"per remote-IP address" or "per peer address" sounds reasonable.

> So I assume no changes needed here?

Well, following the principle of being explicit with magic numbers
dictates that 65528 be explained.  Something like the following may
help in being more explicit:

   s/an offset 65528 bytes/an offset 65528 (8191*8) bytes/

Thanks for entertaining my rather late review.

Ciao,

- vijay

---

From: Fernando Gont <[email-masked]>
Date: Mon, 03 Jan 2011 19:10:56 -0300

Hi, Vijay,

>   s/an offset 65528 bytes/an offset 65528 (8191*8) bytes/

Sounds reasonable. Will do.

> Thanks for entertaining my rather late review.

Thanks *you* for your feedback!

Best regards,