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

[<[e-mail]>]

Peter,

Thank you for your detailed review.  I will provide answers inline and
will adjust the editorial comments in the draft.

Best regards,
Kathleen

-----Original Message-----
From: McCann Peter-A001034 [mailto:[e-mail]] 
Sent: Monday, April 19, 2010 2:40 PM
To: [e-mail]; [e-mail]
Subject: Gen-ART LC Review of draft-moriarty-post-inch-rid-11

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.

------
Response: Attack traffic will continue, but at least this will enable a
way to send definitions of know bad traffic types to participants who
can then decide how to use that information.  It can also provide a
record of the new types of attacks along with new signatures that are
emerging.  The ability to communicate this type of information is
important.  It may start with groups that are willing to set up
agreements, so the consortium approach may take time and may not be
global at first.  If it becomes harder to go undetected, it is harder
for attackers to be successful.  The protocol may have an incremental
effect.  Let's say governments start to adopt this first, even if that
was just in one country, the coordination of information could be quite
useful.
------

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.
-------
Response:
-------
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.

-------
Response:  The FBI is an example of a group that people can reach out to
for assistance.  Should that be left out?  Or should additional
resources from other countries be listed as other examples?  If you have
some you would like added, please let me know and I will add them to the
list.  In the US, the FBI is very helpful when it comes to incident
handling.  Maybe this is true of other organizations that should also be
listed?

I am not sure where you are reading that I think there is one CSIRT?
Several international CSIRTs were involved in this document while it was
in the INCH working group.  I see one reference that might lead you to
that, but the others should lead you away from that thought... is it the
third paragraph of section 4?  The prior ones should have clarified
that.  I'll add a word or two to fix the sentence.

The consortium addition was the request of Steve Bellovin.  I think how
they will be managed is out of scope and if this evolves to use a
consortium, should be defined, but not in this specification.  Should
the use of a consortium be removed completely now?
-------
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?
-------
Response:  Sure, I can change the phrase, no problem.  I'd rather not
expand the document to go into any detection techniques as they can
evolve and is beyond the scope of the document.
-------

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

-------
Response:  Would you prefer to see section 6 be the security
considerations and have section 7 as a sub-section?

-------

Nits/editorial comments:
-------
Response:  Thank you, I will make the suggested updates - I appreciate
the detailed review!
-------

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