Subject: [mile] AD review of draft-ietf-mile-rfc6045-bis

From: Sean Turner <[email-masked]>
Date: Sun, 11 Dec 2011 17:21:18 -0500

Here is my AD review of draft-ietf-mile-rfc6046-bis.

1) s1: I think saying this document updates while the header says 
obsoletes is going to confuse folks:

OLD:

   This specification updates [RFC6045].

NEW:

   This specification obsoletes [RFC6045].

2) s1: Instead of saying this is an updated version of RFC X maybe just 
say RID:

OLD:

  Edits reflected in this updated version of RFC6045 ...

NEW:

  Edits reflected in this updated version of RID ...

3) s1: I think you need to add a new 1st bullet for the changes:

  o This document is on standards track while [RFC6045] was 
informational, but now it's historic.

or something like that.

4) s1: In the summary about schema changes, you should note that the 
schema version was updated.

5) s1.1/s1.2: I think any section that has a normative reference and any 
section that has a 2119 keyword MUST be an normative section.  This 
includes s1 (for [XML1.0]), s1.1 (for [XMLschema]), and s1.2 (for 2119). 
  I'm also thinking s9 might also be normative (it's got SHOULDs in it)? 
  Maybe 1.2 should be aligned with the similar paragraph in 6046-bis.

6) s2: expand NP or is it supposed to be SP?  Also maybe do a global 
replace on NP/network provider with SP/service provider?

7) s3: I think you should re-jiggle the sections to move the normative 
reference to 6046-bis.   Then you can delete this paragraph because it 
would be redundant with the paragraph in s1.1/s1.2.  Maybe have a 
subsection that is about transport or work it in to s3.3:

OLD:

  A RID message uses both
  the IODEF document and RID document, which is encapsulated for
  transport [RFC6046-bis].

NEW:

  A RID message uses both
  the IODEF document and RID document, which MUST be encapsulated for
  transport as specified in [RFC6046-bis].

8) s3s/4.1: I'd strike all the references to the "cloud."  If it had of 
been in 6045 I could see it staying, but it's new.  It's a great 
buzzword that is going to result is whole lotta comments about what is 
it and give me some references.  All of the times it's used it's an 
example so it's not needed because they're really not needed:
-  (Internet backbones or cloud infrastructures)
- An example of a consortium might include the cloud service providers.
- (network, cloud, etc.)
- s4.1: cloud from ClientToSP and SPToClient

9) s3: The reference for X.ridd out to be to 6046-bis - no?

10) s3: I guess this is okay, but it's a mouthful:

  One goal of RID is to prevent the need to permit access to other
  networks' equipment through the use of a standard messaging mechanism
  to enable the communication of incident handling information to other
  providers in a consortium or in neighboring networks.

11) s3: Is it worth adding an informative reference to RFC 6302 in the 
last paragraph?  It's a BCP for internet facing server logging 
recommendations?

12) s?: Is it worth adding an informative reference to 
draft-oreirdan-mody-bot-remediation-18, which is on this weeks IESG 
telechat?

13) s3.1: nit-picking:

OLD:

RID provides a standard protocol and format that is required to ensure 
inter-operability between vendors for the implementation of an incident 
messaging mechanism.

NEW:

RID provides a protocol and format that ensures inter-operability 
between vendors for the implementation of an incident messaging mechanism.

14) s3.5: Which of the message types MUST an implementation support?  Is 
it all of them or just some of them?

15) s4 3rd para: not sure how this fits in with the requirement to use 
TLS.  I assume you're talking about message security here?

16) REQUIRED: Do you want to use required or MUST?  The ITU document 
I've seen makes no mention of mapping REQUIRED (IETF) to SHALL (ITU). 
If ITU is only going to use MUST then maybe you need to change all 
instances of REQUIRED to MUST?

17) s4.1: region: r/Required/REQUIRED
           TrafficType: r/One or many./One or more.  ?
           type.Attack: r/This option should only/This option SHOULD
                          only   (all the other ones are 2119-ed)

18) s4.2: Justification - shouldn't the numbering start at 1?

19) s5.*: Need a reference for XML encryption.  You got one for XMLDsig 
but not XMLEnc.  Why are s5.1 and s5.2:

    Standards for encryption and digital signatures [RFC3275], [XMLsig]:

while s5.3-6 is:

     Standards for encryption and digital signatures [RFC3275]:

20) s5.*: Contains the following:

    The following information is required for Investigation request
    messages and is provided through:

should this be REQUIRED as opposed to required?  I'm taking that 
everything in there MUST be included in the message type?

21) s5.3: contains the following:

      Trace number - used for multiple traces of a single
      incident; must be noted.

What's the must be noted bit about? noted by whom?

22) s5.5: Contains:

    The following data is recommended if available and can be provided
    through:

Should this be RECOMMENDED?

23) s6.1.1: SHA-1 :( Is there anyway you can point to 1.1?  RFC 6194 
suggests strongly considering another hash alg.  Note that it also 
suggests pointing to RFC 6194 if you're specifying SHA-1.  THis should 
probably be in the security considerations.

24) s7: I didn't validate the schema - let me know what tool you used ;)

25) s12.1: Is the June 2008 version considered stable enough to be a 
normative reference?  It's not a W3c recommendation yet.  I think this 
would need to be called out as a DOWNREF.  You got away with it in 6045 
because that RFC was informational.  If you're going to have this 
DOWNREF is there any reason to point to v1 of XMLDsig at all?

26) s8.1: need a reference for the NTP timestamp.

27) s8.1: Could throw in a reference to [RFC3647] for certificate policy 
and certification practices in this sentence:

  The method used SHOULD adhere to any
  certificate policy and practices agreements between entities
  for the use of RID.

I guess I see there's a reference later.

28) s8.3, s.8.4, s8.5: There seems to be some duplication amongst these 
sections.  If s8.3 is about TCP then all you need is the first 
paragraph.  The other two paragraphs are repeated later (or could be 
moved to s8.2).  And, shoudn't this section then be called "Transport 
Protocol" being that TCP is about transport?  And you're not talking 
about security of TCP like TCP-AO so maybe drop the Integrity and 
Authentication?  s8.4 is about dedicated connections but then seems to 
repeat some text from s8.3.  s8.5 is about the Authentication of RID
but then it talks about TLS.  Couldn't you just have one section that 
talked about PKIs and point all the sections there?

29) s8.3: Need a reference to BEEP.

30) s8.3: Note using the RIR's PKI, which they're using for SIDR, would 
be require a pretty big change to their CP.

31) s8.3: I think approved could be removed from the following (also 
ARIN is an RIR):

OLD:

  the American Registry for Internet
  Numbers (ARIN) and the Regional Internet Registry's (RIR's) PKI
  hierarchy, vendor issued certificates, or approved issuers of
  Extended Validation (EV) Certificates.

NEW:

  the Regional Internet Registry's (RIR's) PKI
  hierarchy, vendor issued certificates, or Extended
  Validation (EV) certificate issuers.

32) s8.4: Contains the following:

  In order to address the integrity and authenticity of messages,
  transport encryption MUST be used to secure the traffic sent between
  RID systems.

Are you saying encryption is providing integrity and authentication of 
messages?  I just think this needs to be reworded.

33) s8.4: Wouldn't a better name for this section be "Dedicated 
Connections" or something like that?  It talks about having a dedicated 
connection and how good that is.  Move the 2nd and 3rd paragraphs to s8.2?

34) I went all googlie-eyed in s8.4-8.5.  So I might have more but don't 
wait on them.

35) s8.6: maybe rephrase one of the bullets:

OLD:

  o  A PKI and policy to provide authentication, integrity, and
       privacy.

NEW:

  o A PKI, certificate policy, and certification practice statement
    to provide authentication, integrity, and privacy.

36) s8.6: what does this sentence mean:

  The PKI may be a subordinate CA or in
  the CA hierarchy from the SP's consortium to establish the trust
  relationships necessary as the request is made to other connected
  networks.

If you don't need it I'd just remove it.

37) s8.7: Expand IDSs.

38) s8.7: contains:

    o  Customers MUST know

That's a pretty tall order, maybe all that's really needed is that they 
be informed:

    o  Customers MUST be informed of

same for the next bullet?

39) s9: should the availability be replaced by authentication?
         r/Authenticated encrypted/Protected
         r/of the document contents./of the document contents at the
           application layer.

OLD:

  Trust relationships are based on consortiums and established trust
  relationships of public key infrastructure (PKI) cross-certifications
  of consortiums.

NEW:

  Trust relationships are based on public key infrastructure (PKI).

If you've got a requirement in this section then it's a normative 
section.  THere's one SHOULD here.

spt

---

From: <[email-masked]>
Date: Mon, 12 Dec 2011 22:00:28 -0500

Hi Sean,

Thank you for the detailed review!  Your comments and suggestions have been put into the next revision of RFC6045-bis.  I responded in line to each of the suggestions and put a few up front that either still needs to be done or where there is an outstanding question.

The text for normative/informative will match that decided in RFC6046 for consistency once decided.

KM: I think this is more appropriate for RFC6046-bis since it deals with the IP addresses, port numbers, etc. for logging based on Internet facing hosts.  Let me know if you think otherwise?

KM: I could add a reference or they could add on to RID/RID Transport?  Could this hold up getting the RFC issued if we have to wait for their numbers (if the document doesn't get published first) before our docs referencing it can be published?

23) s6.1.1: SHA-1 :( Is there anyway you can point to 1.1?  RFC 6194
suggests strongly considering another hash alg.  Note that it also
suggests pointing to RFC 6194 if you're specifying SHA-1.  This should
probably be in the security considerations.

Updating the examples to use another algorithm would take care of this issue.  Let me see what I can do here... this should not be a hard fix as long as I can generate the examples.  I have different tools now, so I just need to figure out what I need to do this.  This is the only place SHA-1 shows up, do you want to see a statement in the security considerations section explaining that SHA-1 should not be used, pointing to RFC 6194 if this reference is removed?

28)  Need to fix this one still.  And look at rearranging section 3.

The changes have been made and will be reflected in the next revision.  I have not made a change to have RID envelope IODEF as that is still being discussed and would require all of the examples to be updated in addition to the schema.

Thanks,
Kathleen

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Sean Turner
Sent: Sunday, December 11, 2011 5:21 PM
To: [email-masked]
Subject: [mile] AD review of draft-ietf-mile-rfc6045-bis

OLD:

NEW:

KM: DONE

OLD:

NEW:

KM: DONE

or something like that.

KM: DONE

KM: DONE

KM: Fixed, now SP.

OLD:

  A RID message uses both

NEW:

  A RID message uses both

KM: DONE

KM: DONE: All instances of the word cloud have been removed.

KM: DONE.  Thanks for catching that, I thought all of these references were removed.

KM: Two sentences:
  One goal of RID is to prevent the need to permit access to other
  networks' equipment.  RID provides a standard messaging mechanism
  to enable the communication of incident handling information to other
  providers in a consortium or in neighboring networks.

KM: I think this is more appropriate for RFC6046-bis since it deals with the IP addresses, port numbers, etc. for logging based on Internet facing hosts.

KM: I could add a reference or they could add on to RID/RID Transport?  Could this hold up getting the RFC issued if we have to wait for their numbers (if the document doesn't get published first) before our docs referencing it can be published?

13) s3.1: nit-picking:

OLD:

NEW:

KM: DONE - also changed inter-operability to one word.

KM: All, I adjusted the text at the introduction to make this clear.  Now says:
The six message types that MUST be implemented are as follows:

KM: This is the XML security at the XML document layer.  I see how the first sentence is confusing that point.
The paragraph now reads as follows.

Current text: The security requirements of sending incident information across the
   network include the use of encryption.  The RIDPolicy information is
   not required to be encrypted, so separating out this data from the
   IODEF XML document removes the need for decrypting and parsing the
   IODEF document to determine how it should be handled
   at each RID host.
Proposed text: The security requirements of sending incident information between
   entities  include the use of encryption.  The RIDPolicy information is
   not required to be encrypted, so separating out this data from the
   IODEF extension removes the need for decrypting and parsing the
   entire IODEF and RID document to determine how it should be handled
   at each RID host.

KM: At the last discussion on this topic, SG 17 said they would use RFC2119 language (as referenced in the RFC) and those definitions.  This would keep the UML terminology consistent with RFC5070.  I *think* we should keep it at REQUIRED, but will change it if you think that is preferred.

KM: Fixed REQUIRED
Yes, the second should and has been changed to 'more'
Fixed to SHOULD - thanks, good catches!

KM: Urg!  This is an error with the XML and it has been intermittent.  I will pull up the document in vi to see if anything is hidden that is causing this issue.  Otherwise, I will manually fix before submitting and warn the RFC editor when I send in the XML for the document.

while s5.3-6 is:

KM: Changed all similar statements (6):
Standards for encryption and digital signatures [RFC3275], [XMLsig], [XMLencrypt]:

Thanks for the catch!

KM: Yes, fixed for all message types.  REQUIRED is now used in each.

KM:     Appeared in 4 message types each adjusted as listed below:

        Changed in Result message description to read:
      Trace number - used for multiple traces of a single
      incident; MUST be included if the response is specific to an instance of an incident.

        Investigation Request message:
        Changed to:        Trace number - used for multiple traces of a single
      incident; MUST be included if the InvestigationRequest is an instance of an incident.

      Changed in Result message description to read:
      Trace number - used for multiple traces of a single
      incident; MUST be included if the Report is specific to an instance of an incident.

        IncidentQuery message:
        Changed to:        Trace number - used for multiple traces of a single
      incident; MUST be included if the IncidentQuery is an instance of an incident.

22) s5.5: Contains:

KM: FIXED.  Thanks!

KM:     Updating the examples to use another algorithm would take care of this issue.  Let me see what I can do here... this should not be a hard fix as long as I can generate the examples.  I have different tools now, so I just need to figure out what I need to do this.  This is the only place SHA-1 shows up, do you want to see a statement in the security considerations section explaining that SHA-1 should not be used, pointing to RFC 6194 if this reference is removed?

KM:     Developed in XMLSpy
        Recently validated in several tools, one was
        http://www.w3.org/2001/03/webdata/xsv

        We (I had colleagues help confirm in addition to WG chair validation) did run into an issue with XMLDigSig validating because of slow responses to their web server.  This was confirmed to be the issue, no problems now.

KM:     The link out of RFC6045-bis says it became a W3C recommendation 10 June 2008.  This is the latest version.  They also provide information on 10 implementations and interoperability testing: http://www.w3.org/TR/xmldsig-core/

KM:     This is in IODEF, using the DateTime element of the RecordItem class which references RFC3339.  I changed the text to make sure this is clear as follows:

If an Investigation or TraceRequest does not include a RecordItem entry, a timestamp MUST be used to ensure there is data to be signed for the multi-hop authentication use case.  The DateTime element of the IODEF RecordItem class, [RFC5070] Section 3.19.1, is used for this purpose.

KM:     Since it the reference does not come up for a while, I added here - the first place a CP and CPS are mentioned.

KM: Need to fix this one still.

KM: Added reference to RFC3080, informative.

KM: Thank you for the heads up.  This was just meant as an example...

OLD:

NEW:

KM: DONE, thanks.

KM: No this paragraph is talking about the Transport covered in RFC6046-bis or other possible transports.  I think about this more with reworking section 8.

KM: I'll look at this as well with the changes to section 8.

KM: Please let me know if you do have comments.  This came up as a solution to a problem pointed out by Randy Bush, I believe... a long time ago.  I did update it recently.

OLD:

NEW:

KM: DONE, thanks.

KM: Removed.

37) s8.7: Expand IDSs.

KM: added on first occurrence of IDSs

38) s8.7: contains:

    o  Customers MUST know

KM: DONE: Updated.

OLD:

NEW:

KM: DONE.

KM: DONE.  When I rework section 8, I can try moving this into that section if it makes sense to keep this informative.

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

---

From: Brian Trammell <[email-masked]>
Date: Tue, 13 Dec 2011 06:03:40 +0100

Hi, Kathleen, Sean,

One point inline, below,

Cheers,

Brian (6046 author hat)

> KM: I think this is more appropriate for RFC6046-bis since it deals with the IP addresses, port numbers, etc. for logging based on Internet facing hosts.  Let me know if you think otherwise?

I agree -- I believe this should be referenced from 6046.

---

From: Sean Turner <[email-masked]>
Date: Tue, 13 Dec 2011 08:59:07 -0500

> The text for normative/informative will match that decided in RFC6046 for consistency once decided.

ack

> KM: I think this is more appropriate for RFC6046-bis since it deals with the IP addresses, port numbers, etc. for logging based on Internet facing hosts.  Let me know if you think otherwise?

see earlier message

> KM: I could add a reference or they could add on to RID/RID Transport?  Could this hold up getting the RFC issued if we have to wait for their numbers (if the document doesn't get published first)…

It might, but it's on the telechat for this week so it'll have a month 
head start on RID/RID transport.  I really can't see it holding things up.

> Updating the examples to use another algorithm would take care of this issue.  Let me see what I can do here... this should not be a hard fix as long as I can generate the examples.  I have differe…

I'd say SHOULD NOT SHA-1 and point to 6194.

> The changes have been made and will be reflected in the next revision.  I have not made a change to have RID envelope IODEF as that is still being discussed and would require all of the examples to…

I'll wait to see how the next version looks.

On #16: leaving it as REQUIRED is okay

On #25: My bad it's a recommendation.  This makes me ask: if XMLDsig 
v1.1 adds new algs and supports the nested envelope structures, then do 
you need to refer to RFC3275 at all?  If you don't, then I'd just 
replace [RFC3275] with [XMLSig] everywhere.

spt

---

From: <[email-masked]>
Date: Tue, 13 Dec 2011 09:18:28 -0500

Hi Sean,

For #23, do you want the examples to all be updated or just a statement?

I will look through RFC3275 again to see if it is necessary with XML Digital Signatures 1.1 and replace if appropriate (if nothing is added by the RFC).  There is supposed to be a new version within the year to handle some recent issues.  I think it will be safe to replace as RFC3275 is most likely aligned with the W3C XML Digital Signature version from 2002.

I am in an all day meeting, so my updates will hopefully be ready sometime tonight if possible.  I still need time to focus on the rearranging for sections 3 and 8 as requested.  We also have an issues being discussed as to whether or not RID should envelope IODEF.  This would require all new examples anyway and a schema update to include the optional element for the IODEF schema.

Thanks,
Kathleen

-----Original Message-----
From: Sean Turner [mailto:[email-masked]]
Sent: Tuesday, December 13, 2011 8:59 AM
To: Moriarty, Kathleen
Cc: [email-masked]
Subject: Re: [mile] AD review of draft-ietf-mile-rfc6045-bis

ack

see earlier message

spt

---

From: Sean Turner <[email-masked]>
Date: Tue, 13 Dec 2011 09:31:01 -0500

> For #23, do you want the examples to all be updated or just a statement?

I'd prefer the examples be updated and the statement be made that SHA-1 
is a SHOULD NOT.

> I will look through RFC3275 again to see if it is necessary with XML Digital Signatures 1.1 and replace if appropriate (if nothing is added by the RFC).  There is supposed to be a new version withi…

Unfortunately, the issue they're fixing isn't recent :(

> I am in an all day meeting, so my updates will hopefully be ready sometime tonight if possible.  I still need time to focus on the rearranging for sections 3 and 8 as requested.  We also have an is…

no worries

---

From: Sean Turner <[email-masked]>
Date: Tue, 13 Dec 2011 08:42:53 -0500

On 12/13/11 12:03 AM, Brian Trammell wrote:
> Hi, Kathleen, Sean,
>
> One point inline, below,
>
> Cheers,
>
> Brian (6046 author hat)
>
> On Dec 13, 2011, at 4:00 AM,<[email-masked]>  <[email-masked]>  wrote:
>

That'd work for me.

spt

---

From: Brian Trammell <[email-masked]>
Date: Mon, 19 Dec 2011 23:12:37 +0100

Hi, Sean, all,

On review, I'm not sure recommending 6302-style logging is appropriate in 6046-bis, as the specification as written is essentially NAT-hostile. Specifically, RID has no mechanism for supporting callbacks other than to tcp/4590 on the network-layer address from which the original request came. Given the nature of RID systems within the consortium, I don't necessarily think this is a bad thing (feelings on PNAT-as-transition-mechanism aside): RID is basically a server-to-server protocol, and the servers need to have well known endpoints for identity verification.

So, from the point of view of a RID system, the peer RID system should always have the same address, anyway, which solves the same problem 6302 does.

Cheers,

Brian (author hat)