Real-time Inter-network Defense (RID)
draft-ietf-mile-rfc6045-bis-11

[Ballot comment]
- Expand CSIRT on first use (and maybe include a reference?)

- The FBI is not a good example and not really needed. Precede it
with United States or something if you keep it.

- What is an "intermediate party" (p32) shouldn't stuff like that
be explained up front? What's the model for multiple hops here -
are requests and responses supposed to be passed on without any
controls on the intermediary or not? If not, then what controls
and how do those impact on the protocol?

- Corner case security consideration - related to figure 8, if I
can monitor the n/w connections of SP3, then when SP3 receives a
message from SP2 and then replies to SP2 *and* SP1 then I get to
know for whom SP2 was forwarding the request. Not sure if that's
significant really but I guess it could alert a bad guy to stop
doing stuff before the final tracing stage happens. I guess the
only mitigation would be traffic padding of some sort if (as I
suspect) traffic volunes here are small. (Does RID support traffic
padding?) If you ever allowed an insecure transport then this
might get worse, if the bad guy could flip a bit in the request
and then see the ack to SP1 connection being attempted, then the
bad guy gets his warning but SP3 hasn't got the message.

- 9.3.2 is oddly titled, seems like you're really talking about
a signature being verifiable at many veryifiers.

- I don't get what "In some situations, all network traffic of a
nation may be granted through a single SP.  " means. (p73)

[Ballot comment]
- Expand CSIRT on first use (and maybe include a reference?)

- The FBI is not a good example and not really needed. Precede it
with United States or something if you keep it.

- What is an "intermediate party" (p32) shouldn't stuff like that
be explained up front? What's the model for multiple hops here -
are requests and responses supposed to be passed on without any
controls on the intermediary or not? If not, then what controls
and how do those impact on the protocol?

- Corner case security consideration - related to figure 8, if I
can monitor the n/w connections of SP3, then when SP3 receives a
message from SP2 and then replies to SP2 *and* SP1 then I get to
know for whom SP2 was forwarding the request. Not sure if that's
significant really but I guess it could alert a bad guy to stop
doing stuff before the final tracing stage happens. I guess the
only mitigation would be traffic padding of some sort if (as I
suspect) traffic volunes here are small. (Does RID support traffic
padding?) If you ever allowed an insecure transport then this
might get worse, if the bad guy could flip a bit in the request
and then see the ack to SP1 connection being attempted, then the
bad guy gets his warning but SP3 hasn't got the message.

- 9.3.2 is oddly titled, seems like you're really talking about
a signature being verifiable at many veryifiers.

- I don't get what "In some situations, all network traffic of a
nation may be granted through a single SP.  " means. (p73)

[Ballot discuss]
I've a few things here that are easily fixable I hope after
which I'll be happy to ballot yes.

1) I'd like to understand why LawEnforcement is a good thing to
include here and why its not some form of slippery slope that ends
up going against IETF consensus as represented by rfc2804. This
protocol would contain LawEnforcement and Tracing. I realise
that's not wiretap, but its also not very different. It also
doesn't seem to be technically necessary.  Perhaps a better label
might be "preserve evidence" or something which might also apply
between CSIRTs. (Following on from the response to Robert's
discuss.)

2) LawEnforcement, OfficialBusiness and AccrossNationalBoundaries
are odd. I'm not sure why an Internet protocol should distinguish
between different things like this.  Wouldn't it be silly if there
were a value there for "DealingWithAGuySellingShoes" so I don't
see why any bit of any government is any different for this
protocol. What's done differently on the basis of these fields
that cannot be (maybe better) done based on the identity of the
peer and the transport endpoints used?

3) There seem to be a bunch of 2119 terms misused in 9.5, e.g.
"MUST be addressed" is too vague, ("Yeah, I thought about it, but
I figured I'd do nothing much. Ok I've addressed that";-), "MUST
be informed" is a little ambiguous (would page 99 of a legal
agreement meet the requirement?), "MUST be considered" is too
vague,  "MUST ... adhere ... to goverment ... regulations" is
funny since no one piece of code can do that, etc. etc.  And while
the sentiment behind "must ... not (be) used for ... censorship"
is laudable, I don't see how that can be done.  I think most or
all of the 2119 terms in this section could be profitably
revisisted to be made something with which an implementer or
deployment could be made to conform. (I didn't notice the same
problem in other sections but it might be worth a pass to check.)

[Ballot comment]
The Introduction would be easier to read if the summary of changes since RFC 6045 were moved to an Appendix.

Please expand "FBI" on first use, preferably via "U.S. Federal Bureau of Investigations (FBI)".

Section 4.1.1 introduces the BOOLEAN data type, which is implemented as the xs:boolean type from W3C XML Schema. It would be helpful to note that there are two lexical representations of boolean in XML schema. I suggest changing the text as follows.

OLD
  The BOOLEAN data type is implemented as "xs:boolean" [XMLschema] in
  the schema.

NEW
  The BOOLEAN data type is implemented as "xs:boolean" [XMLschema] in
  the schema.  Note that there are two lexical representations for
  boolean in [XMLschema]: '1' or 'true' for TRUE and '0' or 'false'
  for FALSE.

In Section 5, why is this document defining a 'lang' attribute when any XML data can include the 'xml:lang' attribute via inheritance from the core XML specificiation?

The class definitions are inconsistent. I see several styles, such as:

  One.
  Zero or one.
  One or more.  REQUIRED.
  REQUIRED.  ENUM.
  One or many.  REQUIRED.
  Zero or One. URL.
  Zero to many.

It would help to make those consistent.

Section 5.1 states:

  The RIDPolicy Class includes the ability to embed an IODEF or
  other XML schema document in the ReportSchema element.

I don't think you're embedding XML schema documents, I think you're embedding XML documents that conform to schemas other than IODEF.

Section 5.1 states:

  PolicyRegion

      One or more.  REQUIRED.  The values for the attribute "region" ....

Is that supposed to be "PolicyRegion"?

In Section 5.1.1, is "XMLDocumen" a typo?

In Section 5.3, why is the IncidentSource restricted to FQDNs (Nodes)? It seems that the source of an incident might be an IP address, an email address, etc.

This text in Section 5.4 is confusing:

  The RID schema declares a namespace of "iodef-rid-2.0" and registers
  it per [XMLNames].  Each IODEF-RID document MUST use the
  "iodef-rid-2.0" namespace in the top-level element RID-Document.

In fact the namespace is not "iodef-rid-2.0" but "urn:ietf:params:xml:ns:iodef-rid-2.0". In addition, the "Namespaces in XML 1.0" specification says nothing about registration of XML namespaces; perhaps you meant to cite RFC 3688?

In Section 5.5.1, do you really intend to include schemas, or documents defined by other schemes?

The text in Section 6 is a bit misleading when it says that "The IODEF model MUST be fully implemented to ensure proper parsing of all RID messages." That's true only for RID messages that contain IODEF payloads, not RID messages that contain payloads defined by other schemas.

In Section 8, the XML comment is quite distracting. Why not include this information in the xs:annotation element?

Section 9.1 states:

  o  The originator of a Request MUST use a detached signature to sign
      at least one of the original elements contained in the RecordItem
      class to provide authentication to all upstream participants in
      the trace or those involved in the investigation.

Is this required even in cases where channel encryption (e.g., TLS) is used between the parties to a PeerToPeer exchange that doesn't involve upstream participants? (By the way, it seems that some of the examples in the spec violate the rule from SEction 9.1.)

In Section 9.1, do you mean "MAY" in the text "The IODEF/RID document may be encrypted"? The same question applies to "The action taken in the Result message may be encrypted". The difference between conformance and normal usage is especially confusing in a sentence like this:

  A Request, or any other message type that may be relayed through
  RID systems other than the intended destination as a result of
  trust relationships, may be encrypted for the intended recipient.

I encourage you to check all the text in Section 9.1 (and elsewhere)  to make it clear whether you intend your guidelines to have conformance force.

It's a bit confusing to say in Section 9.1 "See Section 9 for a discussion on public key infrastructure (PKI) and other security requirements." I think you mean Section 9.3. :)

Section 9.2 states:

  The transport specifications are fully defined in a separate document
  [RFC6046-bis].

I think you mean "A transport specification" because it seems that you are leaving the door open to defining other transport bindings in the future.

Section 9.2 states:

  The RID protocol must be able to guarantee delivery and meet the
  necessary security requirements of a state-of-the-art protocol.  In
  order to guarantee delivery, TCP should be considered as the
  underlying protocol within the current network standard practices.

There's a lot more to truly guaranteed delivery at the application layer than simply using TCP as the underlying transport. Do you mean at least once delivery, at most once, or something else? Do messages need to be persisted in case the messaging system crashes? And so on. You might consider dropping this paragraph, or clarifying what you really mean by guaranteed delivery.

I find this a bit confusing:

  Consortiums may vary their selected transport mechanisms and thus
  decide upon a mutual protocol to use for transport when communicating
  with peers in a neighboring consortium using RID.  RID systems MUST
  implement and deploy HTTPS as defined in the transport document
  [RFC6046-bis] and optionally support other protocols such as the
  Blocks Extensible Exchange Protocol (BEEP) [RFC3080].

If consortia are allowed to decide upon their own preferred transport bindings, why is HTTP/TLS a MUST-deploy technology?

As to "optionally support other protocols", clearly someone would need to define bindings for those protocols (BEEP or XMPP or SIP or whatever) before they could be used -- it appears that one can't simply start sending RID documents over those protocols without some definition of the binding (as is already done for things like SOAP). So the current text is a bit misleading.

Section 11 states:

      Registrant Contact: See the "Author's Address" section of this
      document.

However, RFC 3688 states:

  In the case of IETF developed standards, the Registrant will be the IESG.

[Ballot discuss]
First, I'd like to thank you for addressing the comments provided by Larry Masinter in his Apps Directorate review.

There are a few topics I'd like to chat about.

1. The document does not pass ID-nits! You might need to fix the document in order to address the following errors and warnings:

  == Missing Reference: 'XMLschema' is mentioned on line 3519, but not defined

  == Missing Reference: 'RFC5735' is mentioned on line 1811, but not defined

  == Unused Reference: 'CVRF' is defined on line 3720, but no explicit
    reference was found in the text

  ** Downref: Normative reference to an Informational RFC: RFC 3741

  ** Obsolete normative reference: RFC 4646 (Obsoleted by RFC 5646)

  ** Downref: Normative reference to an Informational RFC: RFC 6046

2. This document inherits the definition of Node from the NodeName class in RFC 5070. Although the IODEF specification defines a NodeName as a fully-qualified domain name, it does not provide a definition of that term and specifically does not say whether internationalized domain names (IDNs) are allowed. This is a significant oversight for a modern protocol.

3. The definition of AcrossNationalBoundaries is confusing. First it says that this value must "MUST"?) be set if the message will cross national boundaries (and how exactly is the sender to determine whether the the message will in fact cross national boundaries?). Then it says that this value is ("MUST BE"?) used when additional handling and protection restrictions based on the data type and location, which is not the same thing as crossing national boundaries. Then it says that this value must be set if the security requirements of the message might not apply to all nations. Then it says that this value must be set if the traffic is of a type that may have different restrictions in other nations. This is such a muddle that I don't see how an SP could choose any value other than AcrossNationalBoundaries.

4. In Section 7, some of the examples include XML comments. Are these allowed? Are any other aspects of XML disallowed (e.g., processing instructions and external DTD subsets)? Can conforming applications ignore or reject such data? I think the processing rules and security considerations are underspecified here. At the least, it would be helpful to cite RFC 3270 and RFC 3023 with regard to the use of XML in IETF application protocols.

IANA has a question about the new registry created by
draft-ietf-mile-rfc6045-bis-05.txt (see ACTION 3):

Upon approval of this document, IANA will complete the following actions:

ACTION 1:

IANA will register the following in the XML ns registry at
http://www.iana.org/assignments/xml-registry/ns.html

ID: iodef-rid-2.0
URI: urn:ietf:params:xml:ns:iodef-rid-2.0
Registration template:
http://www.iana.org/assignments/xml-registry/ns/iodef-rid-2.0.txt [not
yet created; will contain template]
Reference: [RFC-to-be]


ACTION 2:

IANA will register the following in the XML schema registry at
http://www.iana.org/assignments/xml-registry/schema.html

ID: iodef-rid-2.0
URI: urn:ietf:params:xml:schema:iodef-rid-2.0
Filename:
http://www.iana.org/assignments/xml-registry/schema/iodef-rid-2.0.xsd
[not yet created; will contain schema provided in Section 8]
Reference: [RFC-to-be]


ACTION 3:

IANA will create the following registry at
http://www.iana.org/assignments/TBD [NOTE: if you want this to be
included on an existing registry page, please let us know and make a
note of it in the document]

Registry Name: XML Schemas Exchanged via RID
Registration Procedure: Specification Required
Reference: [RFC-to-be]

Schema Name: CVRF_1.0
Version: 1.0
Namespace: http://www.icasi.org/CVRF/schema/cvrf/1.0
Specification URI: http://www.icasi.org/cvrf
Reference: [RFC-to-be]

QUESTION: Are these field names copied from section 5.5.1 correct? The
IANA Considerations section appears to contradict itself regarding the
fields to be included in the registry. First it says, "A registry entry
for an XML Schema Transferred via RID consists of" and lists the fields
used above, and then it says "Fields to record in the registry: Schema
Name/Namespace/SchemaID/Specification URI." If the latter is correct,
we're not sure which piece of registration information provided in
section 5.5.1 "Schema ID" refers to.

[Ballot discuss]
(Hit send too soon - sorry - there's an additional comment added at the end)

What motivated the addition of the LawEnforcement PolicyRegion? The other PolicyRegion region definitions give some hint about how the mark might affect processing. It's not clear how this marking this region is required for (or helps) interoperability.

Possibly related - the definition of the OfficialBusiness TrafficType (inherited from 6045) is vague. What an example of an "other official business request" that's not a government request? Is there an example of a request that should use this mark that's not related to a legal investigation?

Can the document make it clearer how either of those enumerated values will be used (not just when a sender might
set them)?

As this is moving from Informational to Standards Track, should there be any policy captured in the document around adding values to PolicyRegion and TrafficType enumerations? (For example, someone may wish to mark messages
moving across HEPA or FERPA controlled boundaries.)

[Ballot discuss]
What motivated the addition of the LawEnforcement PolicyRegion? The other PolicyRegion region definitions give some hint about how the mark might affect processing. It's not clear how this marking this region is required for (or helps) interoperability.

Possibly related - the definition of the OfficialBusiness TrafficType (inherited from 6045) is vague. What an example of an "other official business request" that's not a government request? Is there an example of a request that should use this mark that's not related to a legal investigation?

Can the document make it clearer how either of those enumerated values will be used (not just when a sender might
set them)?

As this is moving from Informational to Standards Track, should there be any policy captured in the document around adding values to PolicyRegion and TrafficType enumerations?

[Ballot comment]
I found the first sentence of the Introduction confusing!             
                                                                         
  This document moves Real-time Inter-network Defense (RID) [RFC6045]
  to Historic status as it provides minor updates.

While I can see that this document moves RFC6045 to Historic, I bet it     
is not your intention to say that RID is Historic.

How about:

  Real-time Inter-network Defense (RID) was previously defined in
  [RFC6045]. This document makes some minor updates to the RID
  specification and moves RID from an informational specification
  onto the standards track. This, this document obsoletes RFC 6045
  and moves it to Historic status.

(Maybe as a standalone paragraph and not running into the the main
text?)

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Real-time Inter-network Defense (RID)) to Proposed Standard


The IESG has received a request from the Managed Incident Lightweight
Exchange WG (mile) to consider the following document:
- 'Real-time Inter-network Defense (RID)'
  as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2012-01-16. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  Security incidents, such as system compromises, worms, viruses,
  phishing incidents, and denial of service, typically result in the
  loss of service, data, and resources both human and system.  Service
  providers and Computer Security Incident Response Teams need to be
  equipped and ready to assist in communicating and tracing security
  incidents with tools and procedures in place before the occurrence of
  an attack.  Real-time Inter-network Defense (RID) outlines a
  proactive inter-network communication method to facilitate sharing
  incident handling data while integrating existing detection, tracing,
  source identification, and mitigation mechanisms for a complete
  incident handling solution.  Combining these capabilities in a
  communication system provides a way to achieve higher security levels
  on networks.  Policy guidelines for handling incidents are
  recommended and can be agreed upon by a consortium using the security
  recommendations and considerations.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-mile-rfc6045-bis/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-mile-rfc6045-bis/


No IPR declarations have been submitted directly on this I-D.

(1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd personally reviewed this version of the
document and, in particular, does he or she believe this
version is ready for forwarding to the IESG for publication?

I, Brian Trammell, am the Document Shepherd for the document. I have reviewed the document, and it is ready for forwarding to the IESG.

(1.b) Has the document had adequate review both from key WG members
and from key non-WG members? Does the Document Shepherd have
any concerns about the depth or breadth of the reviews that
have been performed?

The document was well-discussed on the WG (and pre-WG) mailing list before its adoption as a WG item, and received reviews from within the WG as well as from the applications area during WGLC.

(1.c) Does the Document Shepherd have concerns that the document
needs more review from a particular or broader perspective,
e.g., security, operational complexity, someone familiar with
AAA, internationalization or XML?

No.

(1.d) Does the Document Shepherd have any specific concerns or
issues with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he
or she is uncomfortable with certain parts of the document, or
has concerns whether there really is a need for it. In any
event, if the WG has discussed those issues and has indicated
that it still wishes to advance the document, detail those
concerns here. Has an IPR disclosure related to this document
been filed? If so, please include a reference to the
disclosure and summarize the WG discussion and conclusion on
this issue.

No, and no.

(1.e) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with
others being silent, or does the WG as a whole understand and
agree with it?

There is strong WG consensus on behind the document.

(1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in
separate email messages to the Responsible Area Director. (It
should be in a separate email because this questionnaire is
entered into the ID Tracker.)

No.

(1.g) Has the Document Shepherd personally verified that the
document satisfies all ID nits? (See the Internet-Drafts Checklist
and http://tools.ietf.org/tools/idnits/). Boilerplate checks are
not enough; this check needs to be thorough. Has the document
met all formal review criteria it needs to, such as the MIB
Doctor, media type and URI type reviews?

Yes, and yes. (See 1.h for nits WRT references)

(1.h) Has the document split its references into normative and
informative? Are there normative references to documents that
are not ready for advancement or are otherwise in an unclear
state? If such normative references exist, what is the
strategy for their completion? Are there normative references
that are downward references, as described in [RFC3967]? If
so, list these downward references to support the Area
Director in the Last Call procedure for them [RFC3967].

Yes, and no. The idnits tool appears to incorrectly identify a normative reference to draft-ietf-mile-rfc6046-bis as a downreference to RFC6046 itself; however I have personally verified that no such downreference exists.

(1.i) Has the Document Shepherd verified that the document IANA
consideration section exists and is consistent with the body
of the document? If the document specifies protocol
extensions, are reservations requested in appropriate IANA
registries? Are the IANA registries clearly identified? If
the document creates a new registry, does it define the
proposed initial contents of the registry and an allocation
procedure for future registrations? Does it suggest a
reasonable name for the new registry? See [RFC5226]. If the
document describes an Expert Review process has Shepherd
conferred with the Responsible Area Director so that the IESG
can appoint the needed Expert during the IESG Evaluation?

Yes.

(1.j) Has the Document Shepherd verified that sections of the
document that are written in a formal language, such as XML
code, BNF rules, MIB definitions, etc., validate correctly in
an automated checker?

Yes.

(1.k) The IESG approval announcement includes a Document
Announcement Write-Up. Please provide such a Document
Announcement Write-Up? Recent examples can be found in the
"Action" announcements for approved documents. The approval
announcement contains the following sections:

Technical Summary (from abstract/introduction)

Real-time Inter-network Defense (RID) outlines a proactive inter-network
communication method to facilitate sharing incident handling data while
integrating existing detection, tracing, source identification, and mitigation
mechanisms for a complete incident handling solution. Combining these
capabilities in a communication system provides a way to achieve higher
security levels on networks. The data in RID messages is represented in
an XML document using IODEF [RFC5070] and the RID XML schema defined in this
document.

Working Group Summary

There was extensive commentary on the pre-WG and WG mailing list on the document indicative of review, correction, and consensus. The working group process has been somewhat abbreviated, as the document is an update of an already-published RFC to change its intended status (Informational to Standards Track) and to apply minor updates. Consensus was reached without problems.

Document Quality

The document itself derived from the previously published (informational) RFC 6045. The XML schema was reviewed by two experts, one within the WG and one from outside. In addition to the review received within the MILE WG, much of the content within the document (both technical and editorial) has received extensive review prior to its initial publication as RFC6045 in November 2010.