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

[<[e-mail]>]

Hello Larry,

Thank you again for your review.  Please let me know if the responses below adequately meet your concerns.  If so, I will update the document accordingly.  There are no proposed changes that are technical in nature.  I tried to separate out each question to make it a bit easier to read...


Minor issues:
The "Updates" will be changed to "Obsoletes" in the updated version.  It was listed this way in the 00 version, I'll make sure this is in the template for the document to prevent this from happening.

The document does move from informational to standards track.  Basically, this was a working group item in INCH.  We finalized the work and the working group closed before the documents were published.  Because of the delay, they were published as informational.  Once they were published, interest increased and it is part of the reason driving it for the move for standards track.  The ability to automate the exchange of incident information in a secure way with policy considerations is greatly needed and this specification is getting the most traction to solve the problem.

As mentioned in the previous response, the changes from RFC6045 to RFC6045-bis are included at the end of the introduction.  Please let me know if this addresses your concern.



Details:
Mysterious labels:
ENUM is for enumerated types, building from RFC 5070 which previously defines:
" 2.7.  Enumerated Types

   Enumerated types are represented by the ENUM data type, and consist
   of an ordered list of acceptable values.  Each value has a
   representative keyword.  Within the IODEF schema, the enumerated type
   keywords are used as attribute values.

   The ENUM data type is implemented as a series of "xs:NMTOKEN" in the
   schema."

For attributes that use the ENUM type, It looks like I have "One" listed where "REQUIRED" should be.  This is correct in the schema and I will update the text in the appropriate subsections of 4 to correct this issue.

Would you like to see the definitions from IODEF included in this document or just referenced as is the case now?

Right now, there is section 3.4 that points to IODEF:
"3.4. RID Data Types

   RID is derived from the IODEF data model and inherits all of the data
   types defined in the IODEF model.  One data type is added by RID:
   BOOLEAN."


I'll take the answer for this and replicate it for other data types as needed (definitions, etc.) for how you would like to see it handled.
__________

Next issue is with terms, with one example provided:
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.

This does apply out to any use case where the client can be anything from an individual to an enterprise.  Service provider is intended to be broad to cover many use cases.  I will add more verbiage in this section to clarify the intent.  The objective is really to have this used where there is a client to provider relationship that may be bound by agreements and SLAs where there is typically some trust established through those relationships.  This can also apply to a client and vendor scenario as the vendor may be providing a service.  I'll add the same text to the SPToClient definition as well.

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

Proposed text:
> ClientToSP.  A client initiated the request to their service provider (SP).  A client may be an individual, enterprise, or other type of entity (government, commercial, education, etc.).  A service provider may be a network, telecommunications, cloud, infrastructure, or other type of service provider where a client to vendor relationship has been established.  The client to vendor relationship will typically have established contracts or agreements to define expectations and trust relationships.

2.  SPToClient.  A service provider (SP) initiated a RID request or
    report to a client.  A client may be an individual, enterprise, or other type of entity (government, commercial, education, etc.).  A service provider may be a network, telecommunications, cloud, infrastructure, or other type of service provider where a client to vendor relationship has been established.  The client to vendor relationship will typically have established contracts or agreements to define expectations and trust relationships.

3.  IntraConsortium.  Incident information that should have no
          restrictions within the boundaries of a consortium with the
          agreed-upon use and abuse guidelines. A consortium is a well defined group with established members and trust relationships specific to sharing within that group.  A consortium would typically define the types of data that can be shared in advance, expectations on protecting that data, as well as having established contractual agreements.  Examples of Consortiums may include industry focused sharing communities (Financial, government, research and education, etc.) or cross industry sharing communities (for instance, organizations within local proximity that form a sharing group).

4.  PeerToPeer.  Incident information that should have no
          restrictions between two peers but may require further
          evaluation before continuance beyond that point with the
          agreed-upon use and abuse guidelines.  PeerToPeer communications may involve any two individuals or entities that decide to share information directly with each other.

5.  BetweenConsortiums.  Incident information that should have no
          restrictions between consortiums that have established agreements or contracts with use and abuse guidelines.  BetweenConsortiums is used when two Consortiums (as defined in IntraConsortium above) share data.  The types of data that can be shared BetweenConsortiums should be identified in their agreements and contracts along with expectations on how that data should be handled and protected.

_______

> 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?

Proposed additional text is in quotes.  This does not change the usage, but better explains the capabilities and relationship to IODEF and extensions as well as agreements between entities.

     6.  AcrossNationalBoundaries.  This selection must be set if the
          message type will cross national boundaries.  "AcrossNationalBoundaries is used when data shared may have additional restrictions for handling and protection based on the type of data and where it resides.  The IODEF document included, as well as any extensions, with the RID message should indicate the specific restrictions to be considered.  The national boundary may be defined by existing regulations or other legal agreements specific to a defined region.  The use of this AcrossNationalBoundaries is not legally binding unless contracts and agreements for entities who share data have deemed it as such through additional definitions that may include associated handling and protection requirements."  There could be
          instances of TraceRequest messages where that may not be known
          in advance, but should be known at the instance where
          boundaries are crossed during the investigation.  This must
          also be set if the security requirements of the request is
          based upon regulations of a specific nation that may not apply
          to all nations.  The stricter requirements should be upheld.
          This is different from the "BetweenConsortiums" setting since
          it may be possible to have multiple nations as members of the
          same consortium, and this option must be selected if the
          traffic is of a type that may have different restrictions in
          other nations.
_______________
Next issue was with "LawEnforcement"
>From Larry, " 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 working group discussed this very issue on the mailing list.  I think what is needed is some additional language in the draft to better explain how this is used.  This term was intentionally left ambiguous as the IODEF document included would have the specific contact information of the group the sender interpreted as LawEnforcement.  This could be national or local police or even a government group like the FBI in the US.  Since this could differ around the world, the working group decided that the high level term that may affect how they protect the data and the extent to which it can be shared was good for the RID level.  When you look at the IODEF document, this will include the specific contact information of the recipient (much more granular than the type of Law Enforcement).


Current Text:
>   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 .

Proposed Text:
>   LawEnforcement.  This option is used when incident information is exchanged with LawEnforcement, local government, or other authorities assisting with an investigation.  The usage of this value is interpreted by the sender, and that interpretation may vary in regions of the world.  This value is intentionally broad.  More detailed information on the receiving entity is maintained in the Contact class of the IODEF document.  If the law enforcement agency resides within a different nation that the sending entity, the "AcrossNationalBoundaries" enumeration MUST also be set.
________

The types for TrafficRegion was also raised as a concern, but not as explicitly as the areas above.

In looking at these again, the only change I would suggest at this point is the first sentence of Attack.

Current text:
1.  Attack.  This option should only be selected if the traffic is
          related to a network-based attack.

Proposed text:
1.  Attack.  This option should only be selected if the traffic is
          related to an information security incident or attack.

________

You also raised a question on extensibility.  The WG decided that we wanted to restrict this to the ability to add enumerated values, either through official means (standards document) or to sharing communities who may extend to add their own values.  Throughout the schema, there is an ext-value included, following the established extension mechanism for IODEF.  It points to the definition in RFC5070, section 5.1.  Does this address your concern or would you prefer to see the text included in this document.

I believe this addresses the outstanding questions.  Please let me know if you agree on the proposed text and how each question is addressed.

Thank you,
Kathleen



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

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