[Gen-art] Gen-ART LC Review of draft-moriarty-post-inch-rid-11

["McCann Peter-A001034" <[e-mail]>]

I have been selected as the General Area Review Team (Gen-ART) reviewer
for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-moriarty-post-inch-rid-11
Reviewer: Pete McCann
Review Date: 19 April 2010
IETF LC End Date: 21 April 2010
IESG Telechat date: unknown

Summary:  Needs work

Major issues:

To be effective, this protocol would need to be universally 
deployed and there would need to be a common global policy
about which traffic is abusive and deserving of tracing.
Otherwise, attackers could just hide on uncooperative networks.
Unless we are willing to disconnect these networks from the
Internet (i.e., a consortium of the willing) attack traffic
will continue.  The present document discusses the possibility
of multiple regional or national consortia with different policies.
This could quickly become unworkable or lead to balkanization.

Anyway, this concern is probably not enough to stop the protocol
itself from being published as Informational, but see numerous
minor and editorial comments below.


Minor issues:

Section 3.2:

The last paragraph of this section is confusing.  It says
"RID requires the first 28 bytes of an IP v4 packet" and
justifies this by saying IP is 10 bytes, transport is 10
bytes, and 8 bytes of payload are needed.  But, the IP header
is 20 bytes, and even if you include just the unchanging
fields that still leaves 17.  TCP is also 20 bytes, and UDP
is just 8.  It's not clear what you meant to say here.

Section 4:

A lot of the non-technical requirements described in Section 4
and 4.1 are un-enforceable.  Why do you mention the FBI?  What
about other national law enforcement bodies?  Why do you think
there will be one CSIRT for the whole Internet?  How will such
consortiums be formed and managed?  Suggest leaving this material
out and focusing on the protocol definition.

Section 4.3.2:
   4. Investigation.  This message type is used when the source of the
      traffic is believed to be valid.
Did you mean to say, "when the source IP address of the traffic is
believed
not to be spoofed?"  That's slightly different.  And how exactly would a
target network go about determining this?

A lot of the material in Section 6 looks like it really belongs in the
Security Considerations (Section 7).


Nits/editorial comments:

Abstract:
   mechanisms across for a complete incident
SHOULD BE:
   mechanisms for a complete incident

Section 1 should be titled Introduction.  It would be ok to have
a sub-section labeled "Normative and Informative Sections" but it
should be at the end of the Introduction (and just before the
Terminology
sub-section).

Section 1.2:
   In cases with
SHOULD BE:
   In cases when

   Techniques, such
SHOULD BE:
   Techniques such

   network, have been
SHOULD BE:
   network have been

   necessary level
SHOULD BE:
   a necessary level

Section 1.3:
   without an action take
SHOULD BE:
   without an action taken

The acronym "NP" is used before definition.

Section 2:
   HTTPS or or appropriate
SHOULD BE:
   HTTPS or appropriate

Section 3:
   mitigate the affects
SHOULD BE:
   mitigate the effects

   leave a difficult
SHOULD BE:
   leave the difficult

Section 4:
   either the authority and expertise or the means
SHOULD BE:
   the authority, expertise, and the means

   in which RID messaging
SHOULD BE:
   for which RID messaging

   Routing Arbitor
SHOULD BE:
   Routing Arbiter
Also, should include a reference describing what this is.

Section 4.1:
   a Investigation
SHOULD BE:
   an Investigation

Section 4.2:
   of deceasing
SHOULD BE:
   of decreasing

Section 4.4.3:
   listed is the NP, which located
SHOULD BE:
   listed is the NP that located

Section 4.4.4:
   This message type is used when the source of the
   traffic is believed to be valid.
Again, did you mean, "source IP address is not spoofed?"

Section 4.5.1:
   The originator or the request
SHOULD BE:
   The originator of the request

Section 4.5.1.3:
   This message types only
SHOULD BE:
   This message type only

Section 6.3:
   security functions, utilized in RID requires
SHOULD BE:
   security functions utilized in RID require

Section 6.5:
   read the contents The encryption
SHOULD BE:
   read the contents.  The encryption