Subject: [mile] Comments on latest version of RID (rfc6045-bis-05)

From: "Cichonski, Paul" <[email-masked]>
Date: Wed, 11 Jan 2012 12:07:30 -0500

Kathleen, et al,

A few of us (Dave Waltermire, Rich Struse, and Tom Millar) spent some time
reviewing the latest RID draft and have a few comments that I have listed
below; Dave will be following up with some comments as well.

Some of these comments target the core-structure of RID so I apologize for
not getting them in earlier, but we feel that they are important enough to
merit attention now. These comments focus primarily on ensuring that RID
is as simple as possible so that it is easy for system developers to
understand the intent of the message types and, following from that,
implement RID quickly. It may not be possible to incorporate all these
comments into the current draft, but I think it is still useful to capture
the direction that we think RID should head.

Comments Below ('+' denotes new comment):

+ It seems that there is quite a bit of overlap between the RID message
types of: Investigation (defined in section 6.4) and TraceRequest (defined
in section 6.1). More specifically, TraceRequest seems to be a special
case of Investigation, where it is assumed that the investigation will
have to traverse multiple hops to find the source of the incident. I do
not think there is enough of a difference between these two things to
merit the two distinct message types. From a developer perspective, I
think it makes more sense to deprecate TraceRequest and just add in
normative prose explaining that if an Investigation cannot be completed at
the *next-hop* in the chain, then the *next-hop* should forward the
Investigation message onward (I would imagine the text could just be
copied from the TraceRequest section). If this change is made, then the
IODEF properties from the TraceRequest that are not in Investigation would
have to be moved over to Investigation and made optional.

By deprecating TraceRequest in favor of a more robust Investigation
message type we will significantly reduce the complexity of RID, which I
think will help reduce the barriers to adoption.

+ I think it makes sense to allow a RequestAuthorization message to be
returned from any RID communication message type that initiates
communication (I.e., from an InvestigationRequest, IncidentQuery, or
Report). The RequestAuthorization is essentially a status on how the
request is being processed, so it makes sense to allow it to be returned
for any communication (see last note on potential name change). This also
adds to the simplicity of the spec, since developers can just code that a
RequestAuthorization may be returned from anything, and does not have to
code any semi-complex conditional logic on when to return one.

+ Also for simplicity sake, I think it may be better to say that a
"Result" can be returned from either an InvestigationRequest or a Query,
with the result describing the result of how the request was processed.
This becomes a simple rule of "every message type requesting info/action
will return a result", of course the content of the result will differ
depending on what initiated the communciation.

+ I think it also makes sense for the communication flows from
InvestigationRequest and IncidentQuery to both allow for the return of
zero-or-more Reports to be returned asynchronously. In many cases this
will be needed since the system answering the RID communication may not
have all the information right away and may need to return the data
piecemeal over a period of time.

+ It would be nice to add in a very terse section that provides a
normative description of the possible communication flows based on RID
message types. Section 7 provides a lot of detail on how the communication
may work, but a section listing the communication paths in the simplest
way possible would greatly aid a developer trying to understand what he
has to code. This section would also provide details on if the
communication is expected to be synchronous or asynchronous.

It is probably okay to roll this into the top of section 7; the key here
is to be brief, exact, and simple enough for a developer to get all the
normative rules very quickly and then refer to the more descriptive text
in other sections if needed.

For example, the section would contain sub-sections for those Message
Types that initiate a RID communication and would list the expected return
communication:

1. InvestigationRequest
Description: Asynchronous request for information/action.
Possible Responses:
- RequestAuthorization (optional)
- Result
- Report (zero or more)

2. Incident Query (note: the key difference between InvestigationRequest
and Query is that the first expects some action/state-change on the
receiving system)
Description: Synchronous request for information
Possible Responses:
- RequestAuthorization (optional)
- Result
- Report (zero or more)

3. Report
Description: Asynchronous information report, may be pushed to systems, or
may be sent to systems who had requested it via an InvestigationRequest or
Query.
Possible Responses:
- RequestAuthorization (optional)

+ If possible, I think it would make more sense to change the message type
names to the following:

- Change "RequestAuthorization" to "Acknowledgement": I think
Acknowledgement better reflects what the intention of this message type is
doing: acknowledging the request and possibly providing status on how the
request is being handled.
- Change "Investigation" to "Request": changing it to a verb better
reflects what RID is trying to do (I.e., initiate a request for action),
removing the "Investigation" part makes it a bit more general-purpose,
which will be useful down the road as we find more useful actions that may
not align well with the term Investigation.
- Change "IncidentQuery" to "Query": Same rationale as above, making it
more general purpose will allow us to expand in more directions in the
future.

---

From: <[email-masked]>
Date: Wed, 11 Jan 2012 12:46:40 -0500

Paul,

Thank you very much for the detailed comments.  I think the requests are reasonable and are actually quite simple to fix in the document.  I don't think they will cause significant issues.  I'll describe below and agree they will help developers.  I'll start my responses with KMM on proposed solutions.

Thank you!
Kathleen

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Cichonski, Paul
Sent: Wednesday, January 11, 2012 12:08 PM
To: [email-masked]
Subject: [mile] Comments on latest version of RID (rfc6045-bis-05)

Kathleen, et al,

KMM: Agreed.  This is quite easy to accomplish.  The difference between the IODEF data in the TraceRequest and Investigation is the inclusion of the NPPath information and as you mention, and the concept of tracing through networks.  I will double check, but I believe the Incident request can do this too.  I think the simplest way of handling this to prevent any issues at this point would be to add NPPath capabilities as optional to the Investigation request.  Then keep the section on the TraceRequest, but have it use the Investigation message where the NPPath is required.  The other difference is in the RID MsgType.  I think it is valuable to keep the flag that distinguishes the Traceback capabilities in the now Investigation request message for parsing.  If it were fully automated, the request to trace data may be then sent to the management system for conducting a traceback.

We can state that the full TraceRequest now uses the Investigation message in the updates from RFC6045 section.

Does that address the issue?

The difference between Report and Request are similar as well.  It may make sense to keep this approach consistent for this message type as well where Result would be a variant of Report with added capabilities required and the MsgType enumeration set to Result.  Let me know if this is desired as well to ease implementations.

KMM: This won't require a technical change as this is already permitted.  If you look at the last couple of sentences of 7.3, you can see this is allowed and a use case is provided.  What I will do here is to edit the diagram to show that this is an option.  

Does that meet the request?

KMM: One of the differences for the Result message from the Report message is that the RID IncidentSource class is used.  The other difference is that the NPPath information is included so that the final result will show how the investigation unfolded.  Since this is specific to an Investigation or TraceRequest, I would propose that we instead make Result a variant of Report.  Where you would set the appropriate MsgType (Result) if it was the final response to an Investigation (of either type - assuming the change to have a TraceRequest be a type of Investigation has been made).  From the INCH working group, the CSIRTs through the Report was a better fit for the Query response since it would not include the additional information in the RID schema.  

Let me know what you think of this approach and if it makes sense to also simplify the development effort required.

KMM: I agree this makes sense.  If the other changes are good, we would have a Report set to Result required, but the ability to send Reports that are not the final result during the investigation.  Since Reports can be sent unsolicited with no response required, I think this doesn't really break anything in the protocol, but explicitly states a function that applications will need to provide.

Does that sound good?

1. InvestigationRequest

3. Report

KMM: I agree, this will help add clarity and avoid confusion for developers.  It is not a technical change, so I don't see any issue with adding this in.

KMM: I think this makes more sense, any objections?

KMM: I think this makes sense as well, any objections?

KMM: I think this makes sense as well, any objections?

Thanks again for the detailed review!
Kathleen

_______________________________________________
mile mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mile

---

From: <[email-masked]>
Date: Fri, 13 Jan 2012 14:27:23 -0500

Hi,

I took another look and NPPath is already in the Investigation message (my mistake), so the only real difference is how these are handled by the flag set (MsgType).  This is really quite simple to have the Investigation and TraceRequest implemented once for both purposes.  That makes sense from a developer standpoint and will not break anything in terms of interoperability.  If agreeable, I will have a Request message that can set the flag for either purpose.

Thanks,
Kathleen

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Wednesday, January 11, 2012 12:47 PM
To: [email-masked]; [email-masked]
Subject: Re: [mile] Comments on latest version of RID (rfc6045-bis-05)

Paul,

Thank you!
Kathleen

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Cichonski, Paul
Sent: Wednesday, January 11, 2012 12:08 PM
To: [email-masked]
Subject: [mile] Comments on latest version of RID (rfc6045-bis-05)

Kathleen, et al,

Does that sound good?

1. InvestigationRequest

3. Report

---

From: "Cichonski, Paul" <[email-masked]>
Date: Fri, 13 Jan 2012 14:43:34 -0500

Kathleen,

The change you propose for the Investigation/Trace request sounds good to
me.

One other comment that I had forgotten about: In the "Justification" enum
under the RequestStatus class (section 5.2), can we add the values
"CannotProcess" and "UnrecognizedFormat" to use when the request fails?

As for everything else, I agree with most of your other comments as well;
I included some notes inline below.

Thanks,
Paul

On 1/13/12 2:27 PM, "[email-masked]"
<[email-masked]> wrote:

>Hi,
>
>I took another look and NPPath is already in the Investigation message
>(my mistake), so the only real difference is how these are handled by the
>flag set (MsgType).  This is really quite simple to have the
>Investigation and TraceRequest implemented once for both purposes.  That
>makes sense from a developer standpoint and will not break anything in
>terms of interoperability.  If agreeable, I will have a Request message
>that can set the flag for either purpose.
>
>
>Thanks,
>Kathleen
>
>Thank you very much for the detailed comments.  I think the requests are
>reasonable and are actually quite simple to fix in the document.  I don't
>think they will cause significant issues.  I'll describe below and agree
>they will help developers.  I'll start my responses with KMM on proposed
>solutions.
>
>Thank you!
>Kathleen
>
>KMM: Agreed.  This is quite easy to accomplish.  The difference between
>the IODEF data in the TraceRequest and Investigation is the inclusion of
>the NPPath information and as you mention, and the concept of tracing
>through networks.  I will double check, but I believe the Incident
>request can do this too.  I think the simplest way of handling this to
>prevent any issues at this point would be to add NPPath capabilities as
>optional to the Investigation request.  Then keep the section on the
>TraceRequest, but have it use the Investigation message where the NPPath
>is required.  The other difference is in the RID MsgType.  I think it is
>valuable to keep the flag that distinguishes the Traceback capabilities
>in the now Investigation request message for parsing.  If it were fully
>automated, the request to trace data may be then sent to the management
>system for conducting a traceback.
>
>We can state that the full TraceRequest now uses the Investigation
>message in the updates from RFC6045 section.
>
>The difference between Report and Request are similar as well.  It may
>make sense to keep this approach consistent for this message type as well
>where Result would be a variant of Report with added capabilities
>required and the MsgType enumeration set to Result.  Let me know if this
>is desired as well to ease implementations.
>
>KMM: This won't require a technical change as this is already permitted.
>If you look at the last couple of sentences of 7.3, you can see this is
>allowed and a use case is provided.  What I will do here is to edit the
>diagram to show that this is an option.
>
>KMM: One of the differences for the Result message from the Report
>message is that the RID IncidentSource class is used.  The other
>difference is that the NPPath information is included so that the final
>result will show how the investigation unfolded.  Since this is specific
>to an Investigation or TraceRequest, I would propose that we instead make
>Result a variant of Report.  Where you would set the appropriate MsgType
>(Result) if it was the final response to an Investigation (of either type
>- assuming the change to have a TraceRequest be a type of Investigation
>has been made).  From the INCH working group, the CSIRTs through the
>Report was a better fit for the Query response since it would not include
>the additional information in the RID schema.
>
>Let me know what you think of this approach and if it makes sense to also
>simplify the development effort required.

PC: I see, the Result is actually the result of the investigation/action,
in
which case, a Query would not merit a result. I had thought that the
result was the result of the RID request itself (I.e., how it was
processed). I withdraw this comment, IncidentQuery does not need a Result
since there was no request for action.

>KMM: I agree this makes sense.  If the other changes are good, we would
>have a Report set to Result required, but the ability to send Reports
>that are not the final result during the investigation.  Since Reports
>can be sent unsolicited with no response required, I think this doesn't
>really break anything in the protocol, but explicitly states a function
>that applications will need to provide.
>
>Does that sound good?
>
>KMM: I agree, this will help add clarity and avoid confusion for
>developers.  It is not a technical change, so I don't see any issue with
>adding this in.

PC: If I withdraw the above comment about a Query needed to return a
Result, Incident Query would change to:

2. Incident Query

---

From: <[email-masked]>
Date: Fri, 13 Jan 2012 14:48:09 -0500

Thank you, Paul.

This looks pretty simple and keeps things technically the same.  I think the justifications make sense to add more detail as to why a request may not have been approved.  I'll add the enumerations.

MILE:  I will provide a list of changes to the list with the updated draft on Monday morning after last call ends.  This simplifies it and makes most of the changes text really and could help simplify things for developers.

Thank you,
Kathleen

-----Original Message-----
From: Cichonski, Paul [mailto:[email-masked]] 
Sent: Friday, January 13, 2012 2:44 PM
To: Moriarty, Kathleen; [email-masked]
Subject: Re: Comments on latest version of RID (rfc6045-bis-05)

Kathleen,

Thanks,
Paul

2. Incident Query