Re: [apps-discuss] Request for review: draft-ietf-mile-rfc6045-bis-01

[<[e-mail]>]

Hello Larry,

Thank you very much for the detailed review!  I have a couple of quick questions and will address your concerns with proposed text soon (WGLC ends on Monday, so I can update the document then to include your suggested changes along with any others received).

Can you let me know if the section at the end of the introduction adequately addresses your request for the list of changes from RFC6045?  If not, what additional detail or formatting would be helpful to clear up this request?

I will go back through the terminology again to clarify terms better as requested and to find out if the changes address your concerns (tomorrow or Monday via email to this list).  

A little background:  In this space, groups share data using high level markers to indicate what groups you can share the data with and if it is sensitive.  The markers in RID are more specific than what is used for sharing via email (etc.), but a mapping is easily created.  The "Traffic Light Protocol" just marks incidents as "red", "yellow", "green", and "white" which intends to cover both of those areas.  Organizations decide how they want to share and mark it as such with policy agreements.  The policy part will happen more between groups before they share data.  Sharing in practice occurs when parties know each other and have built a trust relationship or there is a client-vendor relationship.  Hopefully this will expand in the future, but that's how it works now.  It is a delicate balance where parties may want the ability to interpret the terms and map to their policy and create sharing agreements.  Local for instance could be a region defined by a particular sharing group.  The ISACs int he US share across a particular industry, but then there are other groups like the ACSC in the greater Boston area that is cross industry and will limit participation to about 30 organizations for fear that if they get too large, people won't trust (because they don't know the others int he group) and hence won't share.

Thanks again!
Kathleen

________________________________________
From: Larry Masinter [[e-mail]]
Sent: Saturday, December 03, 2011 2:21 PM
To: SM; Moriarty, Kathleen; [e-mail]; [e-mail]
Subject: RE: Request for review: draft-ietf-mile-rfc6045-bis-01

Document:  draft-ietf-mile-rfc6045-bis-01
Title: Real-time Inter-network Defense
Reviewer: Larry Masinter
Review Date: 12/3/2011

Summary:
This draft is not ready for publication as a Proposed Standard and should be revised before publication.

Major issues:
The document defines a language for describing a security incident intended for exchange between services or service providers, but the terminology used for describing incidents and the extensibility and refinement of that terminology is not clear and doesn't seem to be managed.
But this is a preliminary review about the status & intent...

Minor issues:
The status of the document seems to be confusing or incorrect.  The introduction says "This document moves Real-time Inter-network Defense (RID) [RFC6045]    to Historic status as it provides minor updates."  And the status lists that it "updates" RFC 6045.

In fact, the document seems to be a revision of all of RFC 6045
 http://tools.ietf.org/rfcdiff?url1=rfc6045&url2=draft-ietf-mile-rfc6045-bis-01
which moves from "Informational"  to Standards Track.
There doesn't seem to be a summary of "Changes from RFC 6045" which explains what changed, based on actual practice..


Details:

There are several namespaces of enumerated values ("TrafficType", "PolicyRegion", ...) which seem to depend on a common understanding of the meaning of the terminology, but which do not define the terms sufficiently (in my opinion) for anyone to know how to use this.

To pick a couple of examples:

PolicyRegion starts out with "region", and there are mysterious labels. "One. Enum."
There is likely a convention in the document for this, but I think unless it is an explicit table it is better to be more specific.

The bulk of the document contains what seem like definitions of terms in a vocabulary, such as:

> ClientToSP.  An enterprise initiated the request to their service provider.

But the terms "enterprise" and "service provider" are defined ... where? Is my home network an enterprise? What is the scope or scale of an enterprise?  Could different service providers define what an "enterprise" is differently? What is the utility of this value in an incident report?

>   LawEnforcement.  This option is used when incident information is exchanged with LawEnforcement, local government,
>  or other authorities assisting with an investigation.  If the law enforcement agency resides within a different nation that
>  the sending entity, the "crossNationalBoundaries" enumeration MUST also be set .

Again, many undefined terms, and no particular way, indication, hint, of how to clarify them, when they apply, what constitutes a "local government" across the world, etc.   What is a "National Boundary"? Is it a legal jurisdiction? What about security incidents where there is some dispute about what constitutes a "national boundary"? How would one use this value? If you expect consistent processing of incident reports from multiple sources, don't you need to insure common understanding of the terms? And if you don't, why is it standards track?

The extensibility of the protocol is unclear... how are these terms clarified, how do they evolve, what happens when different organizations interpret the terms differently? Is there a registry? Can the set of terms change?

I understand the desire to pass semantic information between multiple parties about security incidents, but I think the fundamental problem is in the management of the evolution of a common understanding of the terminology and namespace supplied.

Larry
--
http://larry.masinter.net