Gen-ART review of draft-ietf-sidr-bgpsec-threats-07
After discussion with the authors, the -07 version of this draft resolves the two issues in the Gen-ART review of the -06 version. In summary: - Text has been added to explain the relationship of the PATHSEC and BGPsec terms. - Citations have been added to the RFCs that explain the RPKI RP caching requirements. Thanks, --David -Original Message- From: Black, David Sent: Monday, September 23, 2013 8:25 PM To: k...@bbn.com; a...@cs.unc.edu; General Area Review Team (gen-...@ietf.org) Cc: Black, David; stbry...@cisco.com; ietf@ietf.org; s...@ietf.org Subject: Gen-ART review of draft-ietf-sidr-bgpsec-threats-06 I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-sidr-bgpsec-threats-06 Reviewer: David L. Black Review Date: September 23, 2012 IETF LC End Date: September 23, 2012 Summary: This draft is on the right track, but has open issues described in the review. This draft describes the threat model for BGP Path Security. The draft generally reads well, but does contain quite a bit of serious security analysis of an important routing protocol and hence requires both security and routing expertise to fully understand. Major issue: This draft contains more than just a threat model. It also contains a high level security analysis of the security architecture/approach that applies the RPKI to secure use of BGP. That analysis appears to be good, but it's somehow disconnected from the rest of the sidr WG's work, by what I hope is simply a terminology problem: - This draft refers to the security architecture/approach for BGP as PATHSEC. - Many of the other sidr WG draft refer to that security as BGPsec In effect, the PATHSEC security architecture/approach appears to be implicit in this draft. Something's missing - if those two terms were meant to be the same, BGPsec should probably be used in this draft, otherwise, the relationship should be described. I've tagged this as a major issue, as it makes text like the following in Section 4.2 rather unclear: Stale Path Announcement: If PATHSEC-secured announcements can expire, such an announcement may be propagated with PATHSEC data that is expired. This behavior would violate the PATHSEC goals and is considered a type of replay attack. What is PATHSEC data? What are the PATHSEC goals? The statement in the abstract that We use the term PATHSEC to refer to any BGP path security technology that makes use of the RPKI doesn't seem to answer these questions. Minor Issue: Section 4.4 seems somewhat loose on caching by RPs, considering the importance of that caching in countering a number of the attacks described in that section - in multiple cases, RP detection of an attack relies upon the RP noticing that something has changed at the publication point wrt the RP's cached copy in a fashion that should not have happened. Statements such as the RPKI calls for RPs to cache and RPs are expected to make use of local caches strike me as a weak foundation for the level of security dependence on that caching. A pointer to a SHOULD or MUST requirement for caching by RPKI RPs in another document would alleviate this concern; surely that language exists somewhere. Nits/editorial comments: Also in Section 4.4: (The RP would be very unhappy if there is no CRL for the CA instance anyway.) Please rewrite to describe how the RP reacts to failure to find a CRL - the RP surely does something in addition to becoming very unhappy ;-). Some of that may already be in the sentence immediately following the very unhappy text. idnits 2.12.17 complains about a missing reference: == Missing Reference: 'TCPMD5' is mentioned on line 114, but not defined That citation is embedded in a quote from RFC 4272, nonetheless, [TCPMD5] should be informatively referenced here - it was RFC 2385, which has been obsoleted by RFC 5925, which is referenced here. The fact that RFC 2385 is obsolete will generate a different idnits warning, which is ok to ignore. Thanks, --David David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 david.bl...@emc.com Mobile: +1 (978) 394-7754
RE: Gen-ART review of draft-ietf-sidr-bgpsec-threats-06
Sounds good - I look forward to seeing the revised draft. Thanks, --David From: Stephen Kent [mailto:k...@bbn.com] Sent: Wednesday, October 02, 2013 11:04 AM To: Black, David Cc: a...@cs.unc.edu; General Area Review Team (gen-...@ietf.org); stbry...@cisco.com; ietf@ietf.org; s...@ietf.org Subject: Re: Gen-ART review of draft-ietf-sidr-bgpsec-threats-06 David, Steve, I think the modified introduction text suffices to connect the PATHSEC and BGPsec terms, but I don't think that referring to the SIDR WG charter for the PATHSEC goals is reasonable - an RFC is an archive document, whereas a WG charter is not. The revised intro text now paraphrases the text from the SIDR charter that describes the path security goals. Steve
RE: Gen-ART review of draft-ietf-sidr-bgpsec-threats-06
Steve, I think the modified introduction text suffices to connect the PATHSEC and BGPsec terms, but I don't think that referring to the SIDR WG charter for the PATHSEC goals is reasonable - an RFC is an archive document, whereas a WG charter is not. The explanation of calls for in the cache discussion is fine. As I previously noted on the TCPMD5 reference: Ok - I was suggesting adding an informative reference to RFC 2385, but this is a nit, and so if the responsible AD is happy with omitting that reference entirely, I don't have a problem. Thanks, --David From: Stephen Kent [mailto:k...@bbn.com] Sent: Tuesday, October 01, 2013 5:08 PM To: Black, David Cc: a...@cs.unc.edu; General Area Review Team (gen-...@ietf.org); stbry...@cisco.com; ietf@ietf.org; s...@ietf.org Subject: Re: Gen-ART review of draft-ietf-sidr-bgpsec-threats-06 David, Since this doc logically precedes the BGPsec design, I still think it's appropriate to use PATHSEC here. But, we can add a sentence to connect the terms. I propose this modified text for the introduction: This document describes the security context in which PATHSEC is intended to operate. (The term PATHSEC is employed in this document to refer to any design used to achieve the path security goal described in the SIDR WG charter. The charter focuses on mechanisms that will enable an AS to determine if the AS_path represented in a route represents the path via which the NLRI traveled. Other SIDR documents use the term BGPsec to refer to a specific design.) ... The phrase calls for seems appropriate in the cache discussion. There is no MUST in the RFCs about using a local cache. The docs encourage RPs to maintain a local cache, and 6481 states that not using one is NOT RECOMMENDED. All of the RP software of which I am aware does so, but it is not an absolute requirement. I think we've agreed that quoted is a static assertion and thus need not be annotated to reflect more recent RFCs. Steve
RE: Gen-ART review of draft-ietf-sidr-bgpsec-threats-06
Steve, [1] Terminology: The term PATHSEC is used to refer to a generic path security solution approach, consistent with the WG charter, rather than to the specific solution approach, BGPsec, that has been developed. The rationale for using the different term is that this threat doc should precede the requirements doc, which should precede the solution design. In reality, the requirements doc was generated before the threat analysis, and the BGPSEC design was well along before this doc was finalized. Earlier versions of the doc did refer to BGPsec, but the term was changed for the reasons cited above. This doc does embed assumptions about what a general path security architecture would entail, e.g., based on prior work on such architectures, e.g, S-BGP. That change in terminology is fine - what's missing (IMHO) is an explanation of how the new terminology relates to terminology used in related drafts. As the term PATHSEC appears to be unique to this draft, I think this draft should explain how that term relates to the BGPsec terminology used elsewhere for a specific instance of the PATHSEC concept. Discussion of related prior work that also falls under the heading of PATHSEC would be good to add (e.g., a sentence or two on S-BGP in addition to BGPsec would make it clear that PATHSEC is the more general term), but I don't view that as essential. That should address most of my concerns around text that I found hard to interpret, e.g., the excerpt from section 4.2 in the original review: Stale Path Announcement: If PATHSEC-secured announcements can expire, such an announcement may be propagated with PATHSEC data that is expired. This behavior would violate the PATHSEC goals and is considered a type of replay attack. What is PATHSEC data? What are the PATHSEC goals? PATHSEC data is whatever data is sent via a path security design to enable an AS to verify that the UPDATE has traversed the indicated set of ASes. The goals for PATHSEC are the ones stated in the SIDR WG charter . (The relevant charter text used to appear up front, but was removed at the request of the WG chairs and the cognizant AD. The relevant text appears in this version on page 16, as part of the residual vulnerabilities discussion.) I think the terminology clarification will clear up what PATHSEC data is, but the notion of describing the goals of an architecture (PATHSEC goals) as residual vulnerabilities strikes me as both peculiar and unclear. [2] Caching The RPKI mandates caching (see RFCs 6480 and 6481), and since use of the RPKI as a basis for PATHSEC is mandated by the SIDR charter, I didn't feel it was necessary to repeat that here. But we can include a cite: Note first that the RPKI calls for RPs to cache the data they acquire and verify from the repository system [RFC6480, RFC6481]. That addition would definitely help. I'd suggest: calls for - requires that I would also observe that it's not a good assumption that the RFC that results from this draft will be read in tandem with the SIDR charter (not much of a problem here, but a more serious problem in [1] above). If that really is intended, then an informative reference to the SIDR charter should be added, although I don't think it's a good idea for an RFC to reference a WG charter - the relevant WG charter portions should be reproduced in the RFC. [3] TCPMD5 reference idnits 2.12.17 complains about a missing reference: == Missing Reference: 'TCPMD5' is mentioned on line 114, but not defined That citation is embedded in a quote from RFC 4272, nonetheless, [TCPMD5] should be informatively referenced here - it was RFC 2385, which has been obsoleted by RFC 5925, which is referenced here. The fact that RFC 2385 is obsolete will generate a different idnits warning, which is ok to ignore. I disagree, and I discussed this with Stewart previously. The reference appears in a quote and was appropriate at the time the quoted text was generated. Ok - I was suggesting adding an informative reference to RFC 2385, but this is a nit, and so if the responsible AD is happy with omitting that reference entirely, I don't have a problem. Thanks, --David From: Stephen Kent [mailto:k...@bbn.com] Sent: Monday, September 30, 2013 2:09 PM To: Black, David Cc: a...@cs.unc.edu; General Area Review Team (gen-...@ietf.org); stbry...@cisco.com; ietf@ietf.org; s...@ietf.org Subject: Re: Gen-ART review of draft-ietf-sidr-bgpsec-threats-06 David, Major issue: This draft contains more than just a threat model. agreed. It also contains a high level security analysis of the security architecture/approach that applies the RPKI to secure use of BGP. yes. we didn't create a threat model doc for the RPKI, and this seemed like a good time to address that omission, since the SIDR charter mandates use of the RPKI as a basis for the path security design. That analysis appears to be good, but it's somehow
RE: Transport Directorate review of: draft-ietf-l2vpn-vpls-mcast-14
Yakov, How about if I'll add the following at the end of 5.5: Aggregation procedures would require two labels stack. This does not introduce any new implications on MTU, as even VPLS multicast supported by ingress replication requires two labels stack. Sure, minor suggestion - two labels stack - two MPLS labels in the label stack (twice). I'd suggest an initial sentence: Replication of traffic within a multicast tree, and flooding of traffic (see section 14) could be employed as traffic amplifiers in denial of service attacks. I'll add this. Ok, but see below for a combined text suggestion that includes ... Followed by a sentence or sentences that list a few important applicable countermeasures (your choice), explaining why each is applicable and indicating where each is described (this document, RFC 4761 or RFC 4762). I would greatly appreciated if you would help me with a sentence or sentences to cover this. I don't think RFC4761 or RFC4762 describe any of such countermeasures. The security considerations section already contains this sentence: As mentioned in [RFC4761], there are two aspects to achieving data privacy and protect against denial-of-service attacks in a VPLS: securing the control plane and protecting the forwarding path. The rest of that paragraph covers data privacy and black-holing. Perhaps just extend the last sentence, e.g.,: OLD In addition, compromise of the control plane could result in black- holing VPLS multicast data. NEW In addition, compromise of the control plane could result in black- holing VPLS multicast data and could provide opportunities for unauthorized VPLS multicast usage (e.g., exploiting traffic replication within a multicast tree to amplify a denial of service attack based on sending large amounts of traffic). Thanks, --David -Original Message- From: Yakov Rekhter [mailto:ya...@juniper.net] Sent: Tuesday, September 24, 2013 8:13 PM To: Black, David Cc: Yakov Rekhter; tsv-...@ietf.org; raggarw...@yahoo.com; y.kam...@ntt.com; luf...@cisco.com; ietf@ietf.org; l2...@ietf.org; stbry...@cisco.com Subject: Re: Transport Directorate review of: draft-ietf-l2vpn-vpls-mcast-14 David, Yakov, First of all, thank you for overlooking the off-by-one error on the year :-) - Review Date: September 23, 2012 IETF LC End Date: September 23, 2012 Of course, 2013 was intended, twice ;-). :-) On the two items (both are editorial, IMHO): (1) The techniques in this draft appear to add an MPLS label to the stack in order to identify the MPLS multicast tree. Does that added label raise any MTU concerns in practice? No more than any other use of label stacking (and there are plenty of other uses of label stacking). I concur, which is why I noted this item as editorial - I don't think it's an actual issue. Furthermore, rfc3032 (MPLS Label Stack Encoding) does cover the MTU issue. A sentence to that effect (lots of uses of label stacking, MTU effects are both well understood and not a problem in practice) with a reference to RFC 3032 should suffice. How about if I'll add the following at the end of 5.5: Aggregation procedures would require two labels stack. This does not introduce any new implications on MTU, as even VPLS multicast supported by ingress replication requires two labels stack. (2) Two techniques used by this draft - replication of traffic within a multicast tree, and flooding of traffic (section 14) - could be employed as traffic amplifiers in denial of service attacks. A short discussion of this possibility and the applicability of countermeasures described in this draft, RFC 4761 and/or RFC 4762 would be good to add to the security considerations section. The Security Consideration section already talks about 4761 and 4762: Security considerations discussed in [RFC4761] and [RFC4762] apply to this document. Suggestion on any additional text would be greatly appreciated. I'd suggest an initial sentence: Replication of traffic within a multicast tree, and flooding of traffic (see section 14) could be employed as traffic amplifiers in denial of service attacks. I'll add this. Followed by a sentence or sentences that list a few important applicable countermeasures (your choice), explaining why each is applicable and indicating where each is described (this document, RFC 4761 or RFC 4762). I would greately appreciated if you would help me with a sentence or sentences to cover this. I don't think RFC4761 or RFC4762 describe any of such countermeasures. Yakov. -Original Message- From: Yakov Rekhter [mailto:ya...@juniper.net] Sent: Tuesday, September 24, 2013 10:27 AM To: Black, David Cc: tsv-...@ietf.org; raggarw...@yahoo.com; y.kam...@ntt.com; luf
RE: Transport Directorate review of: draft-ietf-l2vpn-vpls-mcast-14
Yakov, First of all, thank you for overlooking the off-by-one error on the year :-) - Review Date: September 23, 2012 IETF LC End Date: September 23, 2012 Of course, 2013 was intended, twice ;-). On the two items (both are editorial, IMHO): (1) The techniques in this draft appear to add an MPLS label to the stack in order to identify the MPLS multicast tree. Does that added label raise any MTU concerns in practice? No more than any other use of label stacking (and there are plenty of other uses of label stacking). I concur, which is why I noted this item as editorial - I don't think it's an actual issue. Furthermore, rfc3032 (MPLS Label Stack Encoding) does cover the MTU issue. A sentence to that effect (lots of uses of label stacking, MTU effects are both well understood and not a problem in practice) with a reference to RFC 3032 should suffice. (2) Two techniques used by this draft - replication of traffic within a multicast tree, and flooding of traffic (section 14) - could be employed as traffic amplifiers in denial of service attacks. A short discussion of this possibility and the applicability of countermeasures described in this draft, RFC 4761 and/or RFC 4762 would be good to add to the security considerations section. The Security Consideration section already talks about 4761 and 4762: Security considerations discussed in [RFC4761] and [RFC4762] apply to this document. Suggestion on any additional text would be greatly appreciated. I'd suggest an initial sentence: Replication of traffic within a multicast tree, and flooding of traffic (see section 14) could be employed as traffic amplifiers in denial of service attacks. Followed by a sentence or sentences that list a few important applicable countermeasures (your choice), explaining why each is applicable and indicating where each is described (this document, RFC 4761 or RFC 4762). Thanks, --David -Original Message- From: Yakov Rekhter [mailto:ya...@juniper.net] Sent: Tuesday, September 24, 2013 10:27 AM To: Black, David Cc: tsv-...@ietf.org; raggarw...@yahoo.com; y.kam...@ntt.com; luf...@cisco.com; ya...@juniper.net; ietf@ietf.org; l2...@ietf.org; stbry...@cisco.com; ya...@juniper.net Subject: Re: Transport Directorate review of: draft-ietf-l2vpn-vpls-mcast-14 David, I've reviewed this document as part of the transport area directorate's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors for their information and to allow them to address any issues raised. When done at the time of IETF Last Call, the authors should consider this review together with any other last-call comments they receive. Please always CC tsv-...@ietf.org if you reply to or forward this review. Thanks for your review. Document: draft-ietf-l2vpn-vpls-mcast-14 Reviewer: David L. Black Review Date: September 23, 2012 IETF LC End Date: September 23, 2012 Summary: This draft is basically ready for publication, but has nits that should be fixed before publication. This draft describes multicast optimizations for VPLS via use of MPLS multicast distribution trees within the service provider (SP) network. In general, the techniques in this draft are an improvement, as they should typically result in reduction of SP network traffic required to carry the same level of multicast traffic originating from the VPLS edges. I have reviewed primarily for transport-related topics; while I don't have the expertise to review for MPLS and VPLS concerns, I'm confident in the expertise of this author team in those technologies. I found a couple of items that are effectively editorial: (1) The techniques in this draft appear to add an MPLS label to the stack in order to identify the MPLS multicast tree. Does that added label raise any MTU concerns in practice? No more than any other use of label stacking (and there are plenty of other uses of label stacking). Furthermore, rfc3032 (MPLS Label Stack Encoding) does cover the MTU issue. (2) Two techniques used by this draft - replication of traffic within a multicast tree, and flooding of traffic (section 14) - could be employed as traffic amplifiers in denial of service attacks. A short discussion of this possibility and the applicability of countermeasures described in this draft, RFC 4761 and/or RFC 4762 would be good to add to the security considerations section. The Security Consideration section already talks about 4761 and 4762: Security considerations discussed in [RFC4761] and [RFC4762] apply to this document. Suggestion on any additional text would be greatly appreciated. Yakov. David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA
Gen-ART review of draft-ietf-sidr-bgpsec-threats-06
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-sidr-bgpsec-threats-06 Reviewer: David L. Black Review Date: September 23, 2012 IETF LC End Date: September 23, 2012 Summary: This draft is on the right track, but has open issues described in the review. This draft describes the threat model for BGP Path Security. The draft generally reads well, but does contain quite a bit of serious security analysis of an important routing protocol and hence requires both security and routing expertise to fully understand. Major issue: This draft contains more than just a threat model. It also contains a high level security analysis of the security architecture/approach that applies the RPKI to secure use of BGP. That analysis appears to be good, but it's somehow disconnected from the rest of the sidr WG's work, by what I hope is simply a terminology problem: - This draft refers to the security architecture/approach for BGP as PATHSEC. - Many of the other sidr WG draft refer to that security as BGPsec In effect, the PATHSEC security architecture/approach appears to be implicit in this draft. Something's missing - if those two terms were meant to be the same, BGPsec should probably be used in this draft, otherwise, the relationship should be described. I've tagged this as a major issue, as it makes text like the following in Section 4.2 rather unclear: Stale Path Announcement: If PATHSEC-secured announcements can expire, such an announcement may be propagated with PATHSEC data that is expired. This behavior would violate the PATHSEC goals and is considered a type of replay attack. What is PATHSEC data? What are the PATHSEC goals? The statement in the abstract that We use the term PATHSEC to refer to any BGP path security technology that makes use of the RPKI doesn't seem to answer these questions. Minor Issue: Section 4.4 seems somewhat loose on caching by RPs, considering the importance of that caching in countering a number of the attacks described in that section - in multiple cases, RP detection of an attack relies upon the RP noticing that something has changed at the publication point wrt the RP's cached copy in a fashion that should not have happened. Statements such as the RPKI calls for RPs to cache and RPs are expected to make use of local caches strike me as a weak foundation for the level of security dependence on that caching. A pointer to a SHOULD or MUST requirement for caching by RPKI RPs in another document would alleviate this concern; surely that language exists somewhere. Nits/editorial comments: Also in Section 4.4: (The RP would be very unhappy if there is no CRL for the CA instance anyway.) Please rewrite to describe how the RP reacts to failure to find a CRL - the RP surely does something in addition to becoming very unhappy ;-). Some of that may already be in the sentence immediately following the very unhappy text. idnits 2.12.17 complains about a missing reference: == Missing Reference: 'TCPMD5' is mentioned on line 114, but not defined That citation is embedded in a quote from RFC 4272, nonetheless, [TCPMD5] should be informatively referenced here - it was RFC 2385, which has been obsoleted by RFC 5925, which is referenced here. The fact that RFC 2385 is obsolete will generate a different idnits warning, which is ok to ignore. Thanks, --David David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 david.bl...@emc.com Mobile: +1 (978) 394-7754
Transport Directorate review of: draft-ietf-l2vpn-vpls-mcast-14
I've reviewed this document as part of the transport area directorate's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors for their information and to allow them to address any issues raised. When done at the time of IETF Last Call, the authors should consider this review together with any other last-call comments they receive. Please always CC tsv-...@ietf.org if you reply to or forward this review. Document: draft-ietf-l2vpn-vpls-mcast-14 Reviewer: David L. Black Review Date: September 23, 2012 IETF LC End Date: September 23, 2012 Summary: This draft is basically ready for publication, but has nits that should be fixed before publication. This draft describes multicast optimizations for VPLS via use of MPLS multicast distribution trees within the service provider (SP) network. In general, the techniques in this draft are an improvement, as they should typically result in reduction of SP network traffic required to carry the same level of multicast traffic originating from the VPLS edges. I have reviewed primarily for transport-related topics; while I don't have the expertise to review for MPLS and VPLS concerns, I'm confident in the expertise of this author team in those technologies. I found a couple of items that are effectively editorial: (1) The techniques in this draft appear to add an MPLS label to the stack in order to identify the MPLS multicast tree. Does that added label raise any MTU concerns in practice? (2) Two techniques used by this draft - replication of traffic within a multicast tree, and flooding of traffic (section 14) - could be employed as traffic amplifiers in denial of service attacks. A short discussion of this possibility and the applicability of countermeasures described in this draft, RFC 4761 and/or RFC 4762 would be good to add to the security considerations section. Thanks, --David David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 david.bl...@emc.com Mobile: +1 (978) 394-7754
Gen-ART review of draft-ietf-dime-overload-reqs-12
And the -12 version is likewise ready for publication as an Informational RFC. Thanks, --David -Original Message- From: Black, David Sent: Tuesday, August 27, 2013 12:41 PM To: Ben Campbell Cc: Eric McMurry; General Area Review Team (gen-...@ietf.org); ietf@ietf.org; d...@ietf.org; bcla...@cisco.com; Black, David Subject: Gen-ART review of draft-ietf-dime-overload-reqs-11 The -11 version of this draft addresses all of the nits and editorial comments noted in the Gen-ART review of the -10 version. It's ready for publication as an Informational RFC. Thanks, --David -Original Message- From: Ben Campbell [mailto:b...@nostrum.com] Sent: Thursday, August 22, 2013 4:50 PM To: Black, David Cc: Eric McMurry; General Area Review Team (gen-...@ietf.org); ietf@ietf.org; d...@ietf.org; bcla...@cisco.com Subject: Re: Gen-ART review of draft-ietf-dime-overload-reqs-10 Hi David, We agree on all your points, and will make the updates in the next version, pending shepherd instructions. Thanks! Ben. On Aug 22, 2013, at 2:50 PM, Black, David david.bl...@emc.com wrote: Hi Eric, This looks good - comments follow ... a) I assume that overload control development work will derive more specific security requirements - e.g., as REQ 27 is stated at a rather high level. The discussion in security considerations section seems reasonable. We agree with this. The thinking here was that we didn't want to specify this in a way that would be specific to a particular type of mechanism. It might not hurt to state that assumption, either as a note on Req 27 or in the sec considerations. That would be good to add as a note on REQ 27. The intent was very much as you say, where requirements on individual node capabilities are hoped to result in better overall system behaviors. There are also some requirements that are stated more at the system level (e.g. 7 and 17.) Also the text in section 2.2 that discusses Figure 5 talks about how insufficient server capacity at a cluster of servers behind a Diameter agent can be treated as if the agent itself was overloaded. On the other hand, any mechanism we design will have to focus on actions of individual nodes, so the numbered requirements tend to focus on that. I'm not sure where to change the balance here--do you have specific suggestions? I noted this as editorial rather than a minor issue, as I was mostly concerned that the actual design work will be informed by a sufficient architectural clue that the goal is better overall system behaviors, which your response indicates will definitely be the case ;-). Rather than edit individual requirements, how about adding the following sentence immediately following the introductory sentence in Section 7?: These requirements are stated primarily in terms of individual node behavior to inform the design of the improved mechanism; that design effort should keep in mind that the overall goal is improved overall system behavior across all the nodes involved, not just improved behavior from specific individual nodes. This inadequacy may, in turn, contribute to broader congestion collapse collapse is not the right word here - I suggest issues, impacts, effects or problems. We are fine with any of those alternatives. How about impacts. That's fine. FWIW, congestion collapse has a specific (rather severe) meaning over in the Transport Area, and that meaning was not intended here. 23.843 is the least stable reference. I don't have any issue with pointing that out. The part of it we are referencing is historical front matter though. I'd note the reference as work in progress, and put the statement about stable front matter (historical is a bad work to use here) in the body of the draft that cites the reference. I tried the web and downloaded versions of 2.12.17 and was not able to get the warnings you saw (about the references). What did it say? Sorry, I didn't mean to send you on a wild goose chase :-). The idnits confusion manifested right at the top of the output, where everyone ignores it ... Attempted to download rfc272 state... Failure fetching the file, proceeding without it. You didn't reference RFC 272, so that output's apparently courtesy of idnits misinterpreting this reference: 1195 [TS29.272] 11963GPP, Evolved Packet System (EPS); Mobility Management 1197Entity (MME) and Serving GPRS Support Node (SGSN) related 1198interfaces based on Diameter protocol, TS 29.272 11.4.0, 1199September 2012. I was amused :-). Thanks, --David -Original Message- From: Eric McMurry [mailto:emcmu...@computer.org
Gen-ART review of draft-ietf-dime-overload-reqs-11
The -11 version of this draft addresses all of the nits and editorial comments noted in the Gen-ART review of the -10 version. It's ready for publication as an Informational RFC. Thanks, --David -Original Message- From: Ben Campbell [mailto:b...@nostrum.com] Sent: Thursday, August 22, 2013 4:50 PM To: Black, David Cc: Eric McMurry; General Area Review Team (gen-...@ietf.org); ietf@ietf.org; d...@ietf.org; bcla...@cisco.com Subject: Re: Gen-ART review of draft-ietf-dime-overload-reqs-10 Hi David, We agree on all your points, and will make the updates in the next version, pending shepherd instructions. Thanks! Ben. On Aug 22, 2013, at 2:50 PM, Black, David david.bl...@emc.com wrote: Hi Eric, This looks good - comments follow ... a) I assume that overload control development work will derive more specific security requirements - e.g., as REQ 27 is stated at a rather high level. The discussion in security considerations section seems reasonable. We agree with this. The thinking here was that we didn't want to specify this in a way that would be specific to a particular type of mechanism. It might not hurt to state that assumption, either as a note on Req 27 or in the sec considerations. That would be good to add as a note on REQ 27. The intent was very much as you say, where requirements on individual node capabilities are hoped to result in better overall system behaviors. There are also some requirements that are stated more at the system level (e.g. 7 and 17.) Also the text in section 2.2 that discusses Figure 5 talks about how insufficient server capacity at a cluster of servers behind a Diameter agent can be treated as if the agent itself was overloaded. On the other hand, any mechanism we design will have to focus on actions of individual nodes, so the numbered requirements tend to focus on that. I'm not sure where to change the balance here--do you have specific suggestions? I noted this as editorial rather than a minor issue, as I was mostly concerned that the actual design work will be informed by a sufficient architectural clue that the goal is better overall system behaviors, which your response indicates will definitely be the case ;-). Rather than edit individual requirements, how about adding the following sentence immediately following the introductory sentence in Section 7?: These requirements are stated primarily in terms of individual node behavior to inform the design of the improved mechanism; that design effort should keep in mind that the overall goal is improved overall system behavior across all the nodes involved, not just improved behavior from specific individual nodes. This inadequacy may, in turn, contribute to broader congestion collapse collapse is not the right word here - I suggest issues, impacts, effects or problems. We are fine with any of those alternatives. How about impacts. That's fine. FWIW, congestion collapse has a specific (rather severe) meaning over in the Transport Area, and that meaning was not intended here. 23.843 is the least stable reference. I don't have any issue with pointing that out. The part of it we are referencing is historical front matter though. I'd note the reference as work in progress, and put the statement about stable front matter (historical is a bad work to use here) in the body of the draft that cites the reference. I tried the web and downloaded versions of 2.12.17 and was not able to get the warnings you saw (about the references). What did it say? Sorry, I didn't mean to send you on a wild goose chase :-). The idnits confusion manifested right at the top of the output, where everyone ignores it ... Attempted to download rfc272 state... Failure fetching the file, proceeding without it. You didn't reference RFC 272, so that output's apparently courtesy of idnits misinterpreting this reference: 1195 [TS29.272] 1196 3GPP, Evolved Packet System (EPS); Mobility Management 1197 Entity (MME) and Serving GPRS Support Node (SGSN) related 1198 interfaces based on Diameter protocol, TS 29.272 11.4.0, 1199 September 2012. I was amused :-). Thanks, --David -Original Message- From: Eric McMurry [mailto:emcmu...@computer.org] Sent: Thursday, August 22, 2013 3:06 PM To: Black, David Cc: b...@nostrum.com; General Area Review Team (gen-...@ietf.org); ietf@ietf.org; d...@ietf.org; bcla...@cisco.com Subject: Re: Gen-ART review of draft-ietf-dime-overload-reqs-10 Hi David, Thank you for the review. Your time and comments are appreciated! comments/questions inline. Eric On Aug 17, 2013, at 9:18 , Black, David david.bl...@emc.com wrote: I am
Gen-ART review of draft-ietf-trill-directory-framework-07
The -07 version is also ready for publication as an Informational RFC
Thanks,
--David
-Original Message-
From: gen-art-boun...@ietf.org [mailto:gen-art-boun...@ietf.org] On Behalf Of
Black, David
Sent: Monday, July 29, 2013 7:20 AM
To: ldun...@huawei.com; Donald Eastlake; ra...@alum.mit.edu; igor@yahoo-
inc.com; General Area Review Team
Cc: Ted Lemon; ietf@ietf.org; tr...@ietf.org
Subject: Re: [Gen-art] Gen-ART review of draft-ietf-trill-directory-framework-
06
The -06 version of this draft resolves all of the concerns raised by the Gen-
ART
review of the -05 version - the -06 version is ready for publication as an
Informational RFC.
Thanks,
--David
-Original Message-
From: Black, David
Sent: Wednesday, July 17, 2013 7:54 PM
To: ldun...@huawei.com; Donald Eastlake; ra...@alum.mit.edu; igor@yahoo-
inc.com; General Area Review Team
Cc: tr...@ietf.org; ietf@ietf.org; Black, David; Ted Lemon
Subject: Gen-ART review of draft-ietf-trill-directory-framework-05
Document: draft-ietf-trill-directory-framework-05
Reviewer: David L. Black
Review Date: July 17, 2013
IETF LC End Date: July 18, 2013
Summary:
This draft is on the right track but has open issues, described in the
review.
This draft describes a framework for using directory servers to provide
address mappings (address - destination RBridge) to TRILL Rbridges as an
alternative to data plane learning and use of the TRILL ESADI protocol.
The draft's generally well written and clear. I found a couple of minor
issues.
Major issues: None.
Minor issues:
[1] The last bullet in Section 3.1 says:
- In an environment where VMs migrate, there is a higher chance
of cached information becoming invalid, causing traffic to be
black-holed by the ingress RBridge, that is, persistently sent
to the wrong egress RBridge. If VMs do not flood gratuitous
ARP/ND or VDP [802.1Qbg] messages upon arriving at new
locations, the ingress nodes might not have MAC entries for the
MAC of the newly arrived VMs, causing unknown address flooding.
This is incorrect in multiple ways and should just be removed:
- Persistent black-holing is rare in practice because all common
VM migration implementations issue the gratuitous messages.
- VMs don't send the gratuitous messages, hypervisors do.
- VDP is not flooded. The receiver's always a bridge.
- At least one common VM migration implementation actually uses a gratuitous
RARP, not ARP.
- Flooding is done by the bridges and Rbridges, not the VMs.
[2] There are some unfortunate notation problems in Section 5.1 that carry
into the following sections, based on the logical data structure:
[{IP, MAC/VLAN, {list of attached RBridge nicknames}, {list of
interested RBridges}]
- The first open curly brace ('{') is unmatched.
- Subsequent text uses [IP or MAC/VLAN], IP/MAC/VLAN and MACVLAN,
none of which appear in that structure.
Nits/editorial comments:
Section 1 - item 1 in the numbered list does not explain why it makes
a directory approach attractive. This should be added, as it is
present for the other three items .
Section 2 - Say that IS-IS is a routing protocol.
The definition of Station should say that the node or virtual node
is on a network. Also, please define or explain virtual node.
Section 3.2 - Add the number of entries to be learned to scenario #1
in order to parallel the scenario # 2 discussion.
Section 4 - remove (distributed model) from first paragraph,
as it's not explained.
Section 5.3, top of p.13:
therefore, there needs to be some mechanism by which RBridges that
have pulled information that has not expired can be informed when
that information changes or the like.
or the like is vague. I suggest or becomes invalid for other
reasons.
idnits 2.12.17 didn't find any nits that need attention.
Thanks,
--David
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA 01748
+1 (508) 293-7953 FAX: +1 (508) 293-7786
david.bl...@emc.com Mobile: +1 (978) 394-7754
___
Gen-art mailing list
gen-...@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
RE: Gen-ART review of draft-ietf-dime-overload-reqs-10
Hi Eric, This looks good - comments follow ... a) I assume that overload control development work will derive more specific security requirements - e.g., as REQ 27 is stated at a rather high level. The discussion in security considerations section seems reasonable. We agree with this. The thinking here was that we didn't want to specify this in a way that would be specific to a particular type of mechanism. It might not hurt to state that assumption, either as a note on Req 27 or in the sec considerations. That would be good to add as a note on REQ 27. The intent was very much as you say, where requirements on individual node capabilities are hoped to result in better overall system behaviors. There are also some requirements that are stated more at the system level (e.g. 7 and 17.) Also the text in section 2.2 that discusses Figure 5 talks about how insufficient server capacity at a cluster of servers behind a Diameter agent can be treated as if the agent itself was overloaded. On the other hand, any mechanism we design will have to focus on actions of individual nodes, so the numbered requirements tend to focus on that. I'm not sure where to change the balance here--do you have specific suggestions? I noted this as editorial rather than a minor issue, as I was mostly concerned that the actual design work will be informed by a sufficient architectural clue that the goal is better overall system behaviors, which your response indicates will definitely be the case ;-). Rather than edit individual requirements, how about adding the following sentence immediately following the introductory sentence in Section 7?: These requirements are stated primarily in terms of individual node behavior to inform the design of the improved mechanism; that design effort should keep in mind that the overall goal is improved overall system behavior across all the nodes involved, not just improved behavior from specific individual nodes. This inadequacy may, in turn, contribute to broader congestion collapse collapse is not the right word here - I suggest issues, impacts, effects or problems. We are fine with any of those alternatives. How about impacts. That's fine. FWIW, congestion collapse has a specific (rather severe) meaning over in the Transport Area, and that meaning was not intended here. 23.843 is the least stable reference. I don't have any issue with pointing that out. The part of it we are referencing is historical front matter though. I'd note the reference as work in progress, and put the statement about stable front matter (historical is a bad work to use here) in the body of the draft that cites the reference. I tried the web and downloaded versions of 2.12.17 and was not able to get the warnings you saw (about the references). What did it say? Sorry, I didn't mean to send you on a wild goose chase :-). The idnits confusion manifested right at the top of the output, where everyone ignores it ... Attempted to download rfc272 state... Failure fetching the file, proceeding without it. You didn't reference RFC 272, so that output's apparently courtesy of idnits misinterpreting this reference: 1195 [TS29.272] 1196 3GPP, Evolved Packet System (EPS); Mobility Management 1197 Entity (MME) and Serving GPRS Support Node (SGSN) related 1198 interfaces based on Diameter protocol, TS 29.272 11.4.0, 1199 September 2012. I was amused :-). Thanks, --David -Original Message- From: Eric McMurry [mailto:emcmu...@computer.org] Sent: Thursday, August 22, 2013 3:06 PM To: Black, David Cc: b...@nostrum.com; General Area Review Team (gen-...@ietf.org); ietf@ietf.org; d...@ietf.org; bcla...@cisco.com Subject: Re: Gen-ART review of draft-ietf-dime-overload-reqs-10 Hi David, Thank you for the review. Your time and comments are appreciated! comments/questions inline. Eric On Aug 17, 2013, at 9:18 , Black, David david.bl...@emc.com wrote: I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-dime-overload-reqs-10 Reviewer: David L. Black Review Date: August 17, 2013 IETF LC End Date: August 16, 2013 IESG Telechat date: (if known) Summary: This draft is basically ready for publication, but has nits that should be fixed before publication. This draft describes scenarios in which Diameter overload can occur and provides requirements for development of new overload control functionality in Diameter. It is well written, and the inclusion of scenarios in which overload can occur, both in terms of the relationships among types of Diameter nodes and actual
RE: [karp] IANA policy for draft-ietf-karp-crypto-key-table-08
I'm somewhat uncomfortable with that sort of bar for IANA registries in general, although I have supported it from time to time. (My discomfort with this has grown significantly since my time as an AD). I do not support that sort of bar for this registry. I think we understand each other, but disagree. I believe that is the case (we understand each other, but disagree). The question now is whether you can gain sufficient support to show rough consensus for a change in the document or to show that while there was rough consensus behind the document in the KARP WG, there's a lack of consensus on handling this issue between KARP and some other significant segment of the IETF like the security area. I will simply point to RFC 3365 (Strong Security Requirements for Internet Engineering Task Force Standard Protocols) and suggest that it is relevant to determining what the registration procedure should be based on how this registry is likely to be used and as an example of reasons for the IESG to not follow the rough consensus of a WG. I believe that a discussion of how the registry is likely to be used in practice would be productive, although I am concerned about statements that weak password mechanisms are intended to be in scope, even though the draft (as I read it) excludes them, starting with the draft's title. Thanks, --David -Original Message- From: Sam Hartman [mailto:hartmans-i...@mit.edu] Sent: Friday, August 16, 2013 2:03 PM To: Black, David Cc: Sam Hartman; hous...@vigilsec.com; tim.p...@nist.gov; Dacheng Zhang (zhangdach...@huawei.com); General Area Review Team (gen-...@ietf.org); k...@ietf.org; ietf@ietf.org Subject: Re: [karp] IANA policy for draft-ietf-karp-crypto-key-table-08 Black, == Black, David david.bl...@emc.com writes: Black, done. IMHO, we really should be setting a bar that says Black, that this sort of IETF imprimatur of approval of a crypto Black, algorithm actually means something. Something got manged there. I agree that publishing a standards-track document should endorce the algorithm in question. I'm somewhat uncomfortable with that sort of bar for IANA registries in general, although I have supported it from time to time. (My discomfort with this has grown significantly since my time as an AD). I do not support that sort of bar for this registry. I think we understand each other, but disagree. The question now is whether you can gain sufficient support to show rough consensus for a change in the document or to show that while there was rough consensus behind the document in the KARP WG, there's a lack of consensus on handling this issue between KARP and some other significant segment of the IETF like the security area.
Gen-ART review of draft-ietf-dime-overload-reqs-10
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-dime-overload-reqs-10 Reviewer: David L. Black Review Date: August 17, 2013 IETF LC End Date: August 16, 2013 IESG Telechat date: (if known) Summary: This draft is basically ready for publication, but has nits that should be fixed before publication. This draft describes scenarios in which Diameter overload can occur and provides requirements for development of new overload control functionality in Diameter. It is well written, and the inclusion of scenarios in which overload can occur, both in terms of the relationships among types of Diameter nodes and actual mobile network experience is very helpful. I apologize for this review being a day late, as I've been on vacation for most of this draft's IETF Last Call period. Major issues: (none) Minor issues: (none) Nits/editorial comments: The following two comments could be minor issues, but I'm going to treat them as editorial, as I expect that they will be addressed in development of the actual overload functionality: a) I assume that overload control development work will derive more specific security requirements - e.g., as REQ 27 is stated at a rather high level. The discussion in security considerations section seems reasonable. b) The draft, and especially its requirements in Section 7 are strongly focused on individual Diameter node overload. That's necessary, but overload conditions can be broader, affecting an entire service or application, or multiple instances of either/both, even if not every individual Diameter node involved is overloaded. A number of the requirements, starting with REQ 22 could be generalized to cover broader overload conditions. This (b) has implications for other requirements, e.g., REQ 13 should also be generalized beyond a single node to avoid increased traffic in an overload situation, even from a node that is not overloaded by itself. There are limits on what is reasonable here, as the desired overload functionality is TCP/SCTP- like reaction to congestion where individual actions taken by nodes based on the information they have (which is not the complete state of the network) results in an overall reduction of load. Section 1.2, 2nd paragraph: as network congestion, network congestion can reduce a Diameter nodes nodes - node's Section 5, 1st paragraph: This inadequacy may, in turn, contribute to broader congestion collapse collapse is not the right word here - I suggest issues, impacts, effects or problems. Section 7 The long enumerated list of requirements is not an easy read. It would be better if these could somehow be grouped by functional category, e.g., security, transport interactions, operational/administrative, etc. idnits 2.12.17 noticed the non-standard RFC 2119 boilerplate - this is fine, as the boilerplate has been appropriately modified for this draft that expresses requirements (as opposed to a draft that specifies a protocol). idnits 2.12.17 got confused by the 3GPP and GSMA Informative References. I assume that they're all sufficiently stable to be informative references. However, [TR23.843] is a work in progress, and should be noted as such in its reference - is this needed for any of the other 3GPP or GSMA references? Thanks, --David David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 david.bl...@emc.com Mobile: +1 (978) 394-7754
RE: [karp] IANA policy for draft-ietf-karp-crypto-key-table-08
Sam, Thanks for picking this up. Unlike my other two concerns with this draft, I think we have a longer discussion ahead of us on this one. Your summary of my concern is on the mark: David's main concern is that bad security will get registered. I understand the response to be two-fold: 1) It doesn't matter; the controlling registry for crypto algorithm usage is the protocol-specific registry, not the key table database registry. 2) The guidance for the Expert Reviewer will be very difficult to write. I'm not convinced by either of these, sorry. I'm concerned that the two-registry subtlety in 1) will be lost on implementers, especially because (as mentioned in the IESG thread), this key table database is likely to see use beyond routing protocols. Among other things, it's being proposed as a general mechanism for keying RSVP, not just RSVP-TE (I'm one of the co-chairs of the tsvwg WG that's responsible for RSVP). That key table databases registry is also likely to be a place that designers of new protocols look to figure out what to use for security. As for cleartext passwords: Also, some routing protocols are protected by cleartext passwords sent over the network. We want to be able to manage that, so we will be registering plaintext password in these registries. I don't think anyone will come up with anything worse than that. I read the first sentence in Section 2 of this draft as excluding cleartext passwords: The database is characterized as a table, where each row represents a single long-lived symmetric cryptographic key. If someone wants to argue that a cleartext password is a long-lived symmetric cryptographic key, I'll go break out the popcorn and watch w/amusement :-). Seriously, if the intention is to include cleartext passwords, then I think some more rewriting is in order, and I would suggest checking directly with the Security ADs before going there. As for 2), the fact that it will be difficult (with which I agree) doesn't imply that it isn't necessary or shouldn't be done. IMHO, we really should be setting a bar that says that this sort of IETF imprimatur of approval of a crypto algorithm actually means something. I appreciate that FCFS provides an easier path forward, however I'm reminded by analogy of something I learned from my grad school software engineering professor: I can make the code run arbitrarily fast ... ... if it doesn't have to be correct. I'm rather uncomfortable with this use of process expediency as a rationale for avoiding a technical concern. This may ultimately be an issue that the IESG needs to sort out, as the level of security for IETF protocols and concerns about vanity crypto extend well beyond the karp WG, but discussion ought to start here. Thanks, --David -Original Message- From: Sam Hartman [mailto:hartmans-ie...@mit.edu] Sent: Wednesday, August 14, 2013 3:19 PM To: Black, David Cc: hous...@vigilsec.com; tim.p...@nist.gov; Dacheng Zhang (zhangdach...@huawei.com); General Area Review Team (gen-...@ietf.org); k...@ietf.org; ietf@ietf.org Subject: Re: [karp] IANA policy for draft-ietf-karp-crypto-key-table-08 David, as we mentioned in the IESG thread, we seem to have dropped the response to your comments about IANA actions. WG: From the genart review: [9] I suggest Expert Review for the new IANA registries, not just First Come First Served, so that someone with a security clue can check that the proposed registrations are reasonable. Stephen has filed a related DISCUSS position. He's confused why we need a registry for KDFs or algorithms. He argues that the protocols should already have such a registry. He argues that it would be non-sensical to register a value in this registry but not the protocol registry. In a somewhat related discussion, multiple people have asked what the scope of this document is. Are we defining something for routing protocols? Any security protocol in the world? Something in-between? IU'm going to make two responses: 1) I think FCFS is not harmful for these registries. David's main concern is that bad security will get registered. I'll point out that these registries are not about what security you can use with a routing protocol, but about what security you can configure from a management standpoint. Registering rot13 or similarly questionable security here wouldn't mean I could use it with a routing protocol, only that I could ask a system to do so. If ROT13 was not actually in the security-specific registries for the protocols in question there'd be no way to send a rot13-transformed message. I think people wanting to use bad security in routing protocols will focus on specifying how to use the security for the protocols, and that's the appropriate place to do any gateway review. Yeah, I guess with FCFS it's possible someone could register here and then later realize they cannot get their md4
RE: [karp] Gen-ART review of draft-ietf-karp-crypto-key-table-08
Sam, Thanks for taking another look at this. I think we're in good shape on the IPsec relationship concern, but I think key selection responsibility could use some more attention. [A] The new text on the IPsec relationship looks good - I'd suggest also adding a sentence to state that keys for IPsec pre-shared-key authentication are not appropriate for this key database. [C] The key selection responsibility was not clear to me from the draft - the intent/design stated in your message is fine (and having one key be returned is simpler, and probably more robust than handing multiple keys to different protocol implementations and hoping that they do something consistent): I think we've discussed key selection in the WG and come to a different conclusion. The key table selects the key. We expect peer, key ID, protocol and interface to identify a unique key for an inbound packet. My confusion stems from section 3 starting out by stating that the key database is consulted to find the key to use on an outgoing message followed by several sentences that indicate that the consultation may result in multiple keys. That leads to a suggestion and a question. Suggestion: Add a new paragraph at the start of Section 3 to make the functional responsibility clear: Key selection is the responsibility of the key database functionality; in all cases, the protocol requests a key, and the database returns one key or an indication that there is no matching key. When multiple keys match a protocol's request, the key database selects one as described further in this section. Question: What happens, when despite all the measures described in Section 3, multiple keys match a protocol's request? How does one ensure that the key databases at both ends of the security association return the same key? Thanks, --David -Original Message- From: Sam Hartman [mailto:hartmans-i...@mit.edu] Sent: Wednesday, August 14, 2013 3:32 PM To: Black, David Cc: hous...@vigilsec.com; tim.p...@nist.gov; Dacheng Zhang (zhangdach...@huawei.com); General Area Review Team (gen-...@ietf.org); k...@ietf.org; ietf@ietf.org Subject: Re: [karp] Gen-ART review of draft-ietf-karp-crypto-key-table-08 Black, == Black, David david.bl...@emc.com writes: Black, [A] Overall - I would like to see a paragraph added on how Black, this database conceptually relates to the IPsec Peer Black, Authorization Database (PAD) - see RFC 4301, section 4.4.3. It doesn't. not even a little bit. It's not IPsec; it's not about what key management peers to interact with. It's conceptually similar to the Security Association Database (SAD). In a discussion with Jari I agreed to propose text for a paragraph describing how this interacts with IPsec. If this conceptual database is used to manage to keys for a security protocol that uses IPsec [RFC4301] security services, then the interactions between this conceptual database and the IPsec databases needs to be described by the protocol specification. Typically such a protocol would insert entries into the Security Association Database (SAD) when rows are inserted into the key table and remove SAD entries when key table rows are removed. The protocol specification needs to describe how the SAD entries are constructed along with any other IPsec database entries that are needed, including a description of how these entries are ordered along with other IPsec database entries. The question of whether it is desirable to use this conceptual database to manage protocols that use IPsec security services is open and has not been evaluated. Black, [C] (Section 3) Where does key selection occur? I would Black, suggest that the database return all possible keys and let Black, the protocol figure out what to use. This is particularly Black, important for inbound traffic for obvious reasons. I think we've discussed key selection in the WG and come to a different conclusion. The key table selects the key. We expect peer, key ID, protocol and interface to identify a unique key for an inbound packet. So, I think the concern you raise is not a problem. While there was not a specific thread discussing key selection or this issue, there were multiple reviewers who provided comments on key selection over the development of the document, and making a major change at this point without a technical problem seems undesirable. If I'm missing something and the inbound packet issue is a problem then we need to discuss it.
Gen-ART review of draft-eastlake-rfc5342bis-04
The -04 version of this draft resolves the typo/thinko that snuck into the -03 version, and fixed a number of related instances of that problem that I missed in that review. The -04 version of this draft is ready for publication as a BCP RFC. Thanks, --David -Original Message- From: Black, David Sent: Sunday, June 09, 2013 1:47 PM To: d3e...@gmail.com; joe.ab...@icann.org; General Area Review Team Cc: joe...@bogus.com; ietf@ietf.org; Black, David Subject: Gen-ART review of draft-eastlake-rfc5342bis-03 The -03 version of this draft resolves all of the concerns raised by the Gen-ART review of the -02 version. Unfortunately, a serious typo/thinko snuck into the -03 version (been there, done that, myself). Section 3.2 currently says: 00-42 is a protocol number under the IANA OUI (that is, 00-00-0E-00-42) to be used for documentation purposes. The parenthetical expansion of the protocol number is incorrect. The correct expansion uses -5E- instead of -0E-: 00-42 is a protocol number under the IANA OUI (that is, 00-00-5E-00-42) to be used for documentation purposes. I strongly suggest submitting a -04 version of this draft to make the necessary single character correction (e.g., as opposed to using a RFC Editor Note for that purpose). Thanks, --David -Original Message- From: Black, David Sent: Wednesday, June 05, 2013 6:13 PM To: d3e...@gmail.com; joe.ab...@icann.org; General Area Review Team Cc: Black, David; joe...@bogus.com; ietf@ietf.org Subject: Gen-ART review of draft-eastlake-rfc5342bis-02 I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-eastlake-rfc5342bis-02 Reviewer: David L. Black Review Date: June 5, 2013 IETF LC End Date: June 4, 2013 Summary: This draft is on the right track but has open issues, described in the review. This draft updates the IANA registered Ethernet parameters for IETF use, including recording values assigned for documentation. It also makes some minor changes to IANA procedures. IANA should review this entire draft, not just its IANA Considerations section; Pearl Liang appears to have done that comprehensive review for IANA. Major issues: None Minor issues: One, the IANA review also found this issue. Section 3.2 states: IANA will assign 00-00-0E-00-42 as the protocol number under the IANA OUI to be used for documentation purposes. IANA has not made this assignment, but this assignment request is not recorded in the IANA Considerations section where IANA actions are requested and recorded by IANA after they have been performed. This assignment needs to be added to the IANA Considerations section; see item 5 in the IANA review. Nits/editorial comments: Section 1: This document uses an IESG Ratification process for some assignments. This is not the same process as the IESG Approval process defined in RFC 5226. As those names could be confused by a casual reader who is not strongly familiar with IANA processes, I suggest adding a statement that the IESG Ratification process is defined in this document and is not the same as the IESG Approval process in RFC 5226. This could be added after the sentence that cites RFC 5226. Section 1.4: It would be helpful to point out that there is no OUI assigned for documentation purposes, but there are identifiers based on the IANA OUI that have been assigned for documentation purposes. In general, the use of the acronym IAB for Individual Address Block is unfortunate, but unavoidable, and this is clearly pointed out in the definition of the IAB acronym in section 1.2. Nothing can or should be done about this. idnits 2.12.17 did not find any nits. Thanks, --David David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 david.bl...@emc.com Mobile: +1 (978) 394-7754
Gen-ART review of draft-ietf-karp-crypto-key-table-08
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-karp-crypto-key-table-08 Reviewer: David L. Black Review Date: August 9, 2013 IETF LC End Date: April 29, 2013 IETF Telechat Date: August 15, 2013 Summary: This draft is on the right track, but has open issues described in the review. This draft describes a conceptual key database for use by protocols. It's definitely useful and valuable work, as key management is often an afterthought in protocol design, even when security functionality is actively worked on in the design process. The draft text is in good shape and reads cleanly. The draft authors have addressed most of the issues and concerns from the GenART review of the -07 version of this draft, but three issues remain. I am particularly concerned with the first issue about whether FCFS is appropriate for these security-related registries, and believe that topic deserves IESG discussion. The three issues are ([9], [A] and [C] are the issue identifiers used on the original Gen-ART review of the -07 version of this draft): Major issue: [9] I suggest Expert Review for the new IANA registries, not just First Come First Served, so that someone with a security clue can check that the proposed registrations are reasonable. Minor issues: [A] Overall - I would like to see a paragraph added on how this database conceptually relates to the IPsec Peer Authorization Database (PAD) - see RFC 4301, section 4.4.3. [C] (Section 3) Where does key selection occur? I would suggest that the database return all possible keys and let the protocol figure out what to use. This is particularly important for inbound traffic for obvious reasons. Nits/editorial comments: First paragraph in 8.1.2 should be at end of 8.1.1. idnits 2.12.17 found two nits - the latter one (2119 reference/boilerplate) needs attention: ** There are 2 instances of too long lines in the document, the longest one being 6 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 194: '...tion of key material. The KDF MAY use...' RFC 2119 keyword, line 196: '... or received but MUST NOT depend on ot...' Thanks, --David David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 david.bl...@emc.com Mobile: +1 (978) 394-7754
RE: Gen-ART review of draft-ietf-trill-directory-framework-06
The -06 version of this draft resolves all of the concerns raised by the Gen-ART
review of the -05 version - the -06 version is ready for publication as an
Informational RFC.
Thanks,
--David
-Original Message-
From: Black, David
Sent: Wednesday, July 17, 2013 7:54 PM
To: ldun...@huawei.com; Donald Eastlake; ra...@alum.mit.edu; igor@yahoo-
inc.com; General Area Review Team
Cc: tr...@ietf.org; ietf@ietf.org; Black, David; Ted Lemon
Subject: Gen-ART review of draft-ietf-trill-directory-framework-05
Document: draft-ietf-trill-directory-framework-05
Reviewer: David L. Black
Review Date: July 17, 2013
IETF LC End Date: July 18, 2013
Summary:
This draft is on the right track but has open issues, described in the review.
This draft describes a framework for using directory servers to provide
address mappings (address - destination RBridge) to TRILL Rbridges as an
alternative to data plane learning and use of the TRILL ESADI protocol.
The draft's generally well written and clear. I found a couple of minor
issues.
Major issues: None.
Minor issues:
[1] The last bullet in Section 3.1 says:
- In an environment where VMs migrate, there is a higher chance
of cached information becoming invalid, causing traffic to be
black-holed by the ingress RBridge, that is, persistently sent
to the wrong egress RBridge. If VMs do not flood gratuitous
ARP/ND or VDP [802.1Qbg] messages upon arriving at new
locations, the ingress nodes might not have MAC entries for the
MAC of the newly arrived VMs, causing unknown address flooding.
This is incorrect in multiple ways and should just be removed:
- Persistent black-holing is rare in practice because all common
VM migration implementations issue the gratuitous messages.
- VMs don't send the gratuitous messages, hypervisors do.
- VDP is not flooded. The receiver's always a bridge.
- At least one common VM migration implementation actually uses a gratuitous
RARP, not ARP.
- Flooding is done by the bridges and Rbridges, not the VMs.
[2] There are some unfortunate notation problems in Section 5.1 that carry
into the following sections, based on the logical data structure:
[{IP, MAC/VLAN, {list of attached RBridge nicknames}, {list of
interested RBridges}]
- The first open curly brace ('{') is unmatched.
- Subsequent text uses [IP or MAC/VLAN], IP/MAC/VLAN and MACVLAN,
none of which appear in that structure.
Nits/editorial comments:
Section 1 - item 1 in the numbered list does not explain why it makes
a directory approach attractive. This should be added, as it is
present for the other three items .
Section 2 - Say that IS-IS is a routing protocol.
The definition of Station should say that the node or virtual node
is on a network. Also, please define or explain virtual node.
Section 3.2 - Add the number of entries to be learned to scenario #1
in order to parallel the scenario # 2 discussion.
Section 4 - remove (distributed model) from first paragraph,
as it's not explained.
Section 5.3, top of p.13:
therefore, there needs to be some mechanism by which RBridges that
have pulled information that has not expired can be informed when
that information changes or the like.
or the like is vague. I suggest or becomes invalid for other
reasons.
idnits 2.12.17 didn't find any nits that need attention.
Thanks,
--David
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA 01748
+1 (508) 293-7953 FAX: +1 (508) 293-7786
david.bl...@emc.com Mobile: +1 (978) 394-7754
RE: Gen-ART review of draft-ietf-trill-directory-framework-05
Hi Donald,
All of your responses are fine with me.
Thanks,
--David
-Original Message-
From: Donald Eastlake [mailto:d3e...@gmail.com]
Sent: Friday, July 19, 2013 7:56 AM
To: Black, David
Cc: ldun...@huawei.com; ra...@alum.mit.edu; i...@yahoo-inc.com; General Area
Review Team; tr...@ietf.org; ietf@ietf.org; Ted Lemon
Subject: Re: Gen-ART review of draft-ietf-trill-directory-framework-05
Hi David,
Thanks for the review. See responses below.
On Wed, Jul 17, 2013 at 7:54 PM, Black, David david.bl...@emc.com wrote:
Document: draft-ietf-trill-directory-framework-05
Reviewer: David L. Black
Review Date: July 17, 2013
IETF LC End Date: July 18, 2013
Summary:
This draft is on the right track but has open issues, described in the
review.
This draft describes a framework for using directory servers to provide
address mappings (address - destination RBridge) to TRILL Rbridges as an
alternative to data plane learning and use of the TRILL ESADI protocol.
The draft's generally well written and clear. I found a couple of minor
issues.
Thanks.
Major issues: None.
Minor issues:
[1] The last bullet in Section 3.1 says:
- In an environment where VMs migrate, there is a higher chance
of cached information becoming invalid, causing traffic to be
black-holed by the ingress RBridge, that is, persistently sent
to the wrong egress RBridge. If VMs do not flood gratuitous
ARP/ND or VDP [802.1Qbg] messages upon arriving at new
locations, the ingress nodes might not have MAC entries for the
MAC of the newly arrived VMs, causing unknown address flooding.
This is incorrect in multiple ways and should just be removed:
OK.
- Persistent black-holing is rare in practice because all common
VM migration implementations issue the gratuitous messages.
- VMs don't send the gratuitous messages, hypervisors do.
- VDP is not flooded. The receiver's always a bridge.
- At least one common VM migration implementation actually uses a gratuitous
RARP, not ARP.
- Flooding is done by the bridges and Rbridges, not the VMs.
[2] There are some unfortunate notation problems in Section 5.1 that carry
into the following sections, based on the logical data structure:
[{IP, MAC/VLAN, {list of attached RBridge nicknames}, {list of
interested RBridges}]
- The first open curly brace ('{') is unmatched.
- Subsequent text uses [IP or MAC/VLAN], IP/MAC/VLAN and MACVLAN,
none of which appear in that structure.
We'll try to clean that up.
Nits/editorial comments:
Section 1 - item 1 in the numbered list does not explain why it makes
a directory approach attractive. This should be added, as it is
present for the other three items .
I suggest combining point 1 with the material just before the table
and re-numbering points 2-4 to be 1-3.
Section 2 - Say that IS-IS is a routing protocol.
The definition of Station should say that the node or virtual node
is on a network. Also, please define or explain virtual node.
OK on the first two points. On virtual node, that is only used in
the definition of station which is different from the definition of
end station. However, looking through the document, there was only
one instance of station without end before it and that instance
was talking about end stations. So I propose to remove the definition
of station and to insert end before the one occurrence of
station in the body of the document not already preceded by end.
Section 3.2 - Add the number of entries to be learned to scenario #1
in order to parallel the scenario # 2 discussion.
OK.
Section 4 - remove (distributed model) from first paragraph,
as it's not explained.
OK.
Section 5.3, top of p.13:
therefore, there needs to be some mechanism by which RBridges that
have pulled information that has not expired can be informed when
that information changes or the like.
or the like is vague. I suggest or becomes invalid for other
reasons.
OK.
Thanks,
Donald
=
Donald E. Eastlake 3rd +1-508-333-2270 (cell)
155 Beaver Street, Milford, MA 01757 USA
d3e...@gmail.com
idnits 2.12.17 didn't find any nits that need attention.
Thanks,
--David
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA 01748
+1 (508) 293-7953 FAX: +1 (508) 293-7786
david.bl...@emc.comMobile: +1 (978) 394-7754
Gen-ART review of draft-ietf-trill-directory-framework-05
Document: draft-ietf-trill-directory-framework-05
Reviewer: David L. Black
Review Date: July 17, 2013
IETF LC End Date: July 18, 2013
Summary:
This draft is on the right track but has open issues, described in the review.
This draft describes a framework for using directory servers to provide
address mappings (address - destination RBridge) to TRILL Rbridges as an
alternative to data plane learning and use of the TRILL ESADI protocol.
The draft's generally well written and clear. I found a couple of minor
issues.
Major issues: None.
Minor issues:
[1] The last bullet in Section 3.1 says:
- In an environment where VMs migrate, there is a higher chance
of cached information becoming invalid, causing traffic to be
black-holed by the ingress RBridge, that is, persistently sent
to the wrong egress RBridge. If VMs do not flood gratuitous
ARP/ND or VDP [802.1Qbg] messages upon arriving at new
locations, the ingress nodes might not have MAC entries for the
MAC of the newly arrived VMs, causing unknown address flooding.
This is incorrect in multiple ways and should just be removed:
- Persistent black-holing is rare in practice because all common
VM migration implementations issue the gratuitous messages.
- VMs don't send the gratuitous messages, hypervisors do.
- VDP is not flooded. The receiver's always a bridge.
- At least one common VM migration implementation actually uses a gratuitous
RARP, not ARP.
- Flooding is done by the bridges and Rbridges, not the VMs.
[2] There are some unfortunate notation problems in Section 5.1 that carry
into the following sections, based on the logical data structure:
[{IP, MAC/VLAN, {list of attached RBridge nicknames}, {list of
interested RBridges}]
- The first open curly brace ('{') is unmatched.
- Subsequent text uses [IP or MAC/VLAN], IP/MAC/VLAN and MACVLAN,
none of which appear in that structure.
Nits/editorial comments:
Section 1 - item 1 in the numbered list does not explain why it makes
a directory approach attractive. This should be added, as it is
present for the other three items .
Section 2 - Say that IS-IS is a routing protocol.
The definition of Station should say that the node or virtual node
is on a network. Also, please define or explain virtual node.
Section 3.2 - Add the number of entries to be learned to scenario #1
in order to parallel the scenario # 2 discussion.
Section 4 - remove (distributed model) from first paragraph,
as it's not explained.
Section 5.3, top of p.13:
therefore, there needs to be some mechanism by which RBridges that
have pulled information that has not expired can be informed when
that information changes or the like.
or the like is vague. I suggest or becomes invalid for other
reasons.
idnits 2.12.17 didn't find any nits that need attention.
Thanks,
--David
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA 01748
+1 (508) 293-7953 FAX: +1 (508) 293-7786
david.bl...@emc.com Mobile: +1 (978) 394-7754
RE: Gen-ART review of draft-ietf-abfab-eapapplicability-05
And the -05 version includes the text to address that editorial nit - it's ready for publication as a Proposed Standard RFC. Many thanks to the authors for productively addressing the review comments. Thanks, --David -Original Message- From: Black, David Sent: Monday, July 08, 2013 4:44 PM To: Black, David; stefan.win...@restena.lu; jsalo...@cisco.com; General Area Review Team Cc: ietf@ietf.org; ab...@ietf.org Subject: Gen-ART review of draft-ietf-abfab-eapapplicability-04 The -04 version of this draft resolves the minor issue noted in the Gen-ART review of the -03 version. There is a remaining editorial nit, in that the one use of non-network in the -04 version would benefit from clarification. I suggest the following text change to the start of the paragraph that's split across pages 3 and 4 (change is to last line of excerpt): OLD Operators need to carefully consider the security implications before relaxing these requirements. One potentially serious attack exists when channel binding is not required and EAP authentication is introduced into an existing non-network service. NEW Operators need to carefully consider the security implications before relaxing these requirements. One potentially serious attack exists when channel binding is not required and EAP authentication is introduced into an existing service other than network access. Thanks, --David -Original Message- From: Black, David Sent: Monday, June 17, 2013 10:39 PM To: stefan.win...@restena.lu; jsalo...@cisco.com; General Area Review Team Cc: ietf@ietf.org; ab...@ietf.org; Black, David Subject: Gen-ART review of draft-ietf-abfab-eapapplicability-03 I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-abfab-eapapplicability-03 Reviewer: David L. Black Review Date: June 17, 2003 IETF LC End Date: June 17, 2003 Summary: This draft is on the right track but has open issues, described in the review. This draft updates the applicability statement for EAP to include usage for application layer access via EAP over GSSAPI. Additional security requirements are introduced for environments in which EAP is used for that purpose. I found one open issue, which is minor, and may be editorial Major issues: None Minor issues: One The next to last paragraph on p.3 begins with this sentence: For these reasons, channel binding MUST be implemented by peers, EAP servers and AAA servers in environments where EAP authentication is used to access application layer services. It appear that this MUST requirement applies to all uses of EAP, including network access authentication, not just application layer access authentication. If so, that's not immediately obvious from the text, and an additional sentence should be added to make this clearer. If not, the above sentence needs to exclude network access authentication from that requirement. Nits/editorial comments: The same paragraph (p.3) continues with: In addition, channel binding MUST default to being required by peers for non-network authentication. If the EAP server is aware that authentication is for something other than a network service, it too MUST default to requiring channel binding. What is meant by non-network authentication and other than a network service? If those mean other than for network access authentication as the term network access authentication is used in section 1 and RFC 3748, that meaning should be clarified. idnits 2.12.17 generated this comment: -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at http://trustee.ietf.org/license-info for more information.) idnits appears to be confused ;-). The -00 version of this draft is from 2012, and this draft does not contain sufficient material from RFC 3748 that would raise that concern, so this comment should be ok to ignore. Thanks, --David David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 david.bl...@emc.com Mobile: +1 (978) 394-7754
Gen-ART review of draft-ietf-abfab-eapapplicability-04
The -04 version of this draft resolves the minor issue noted in the Gen-ART review of the -03 version. There is a remaining editorial nit, in that the one use of non-network in the -04 version would benefit from clarification. I suggest the following text change to the start of the paragraph that's split across pages 3 and 4 (change is to last line of excerpt): OLD Operators need to carefully consider the security implications before relaxing these requirements. One potentially serious attack exists when channel binding is not required and EAP authentication is introduced into an existing non-network service. NEW Operators need to carefully consider the security implications before relaxing these requirements. One potentially serious attack exists when channel binding is not required and EAP authentication is introduced into an existing service other than network access. Thanks, --David -Original Message- From: Black, David Sent: Monday, June 17, 2013 10:39 PM To: stefan.win...@restena.lu; jsalo...@cisco.com; General Area Review Team Cc: ietf@ietf.org; ab...@ietf.org; Black, David Subject: Gen-ART review of draft-ietf-abfab-eapapplicability-03 I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-abfab-eapapplicability-03 Reviewer: David L. Black Review Date: June 17, 2003 IETF LC End Date: June 17, 2003 Summary: This draft is on the right track but has open issues, described in the review. This draft updates the applicability statement for EAP to include usage for application layer access via EAP over GSSAPI. Additional security requirements are introduced for environments in which EAP is used for that purpose. I found one open issue, which is minor, and may be editorial Major issues: None Minor issues: One The next to last paragraph on p.3 begins with this sentence: For these reasons, channel binding MUST be implemented by peers, EAP servers and AAA servers in environments where EAP authentication is used to access application layer services. It appear that this MUST requirement applies to all uses of EAP, including network access authentication, not just application layer access authentication. If so, that's not immediately obvious from the text, and an additional sentence should be added to make this clearer. If not, the above sentence needs to exclude network access authentication from that requirement. Nits/editorial comments: The same paragraph (p.3) continues with: In addition, channel binding MUST default to being required by peers for non-network authentication. If the EAP server is aware that authentication is for something other than a network service, it too MUST default to requiring channel binding. What is meant by non-network authentication and other than a network service? If those mean other than for network access authentication as the term network access authentication is used in section 1 and RFC 3748, that meaning should be clarified. idnits 2.12.17 generated this comment: -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at http://trustee.ietf.org/license-info for more information.) idnits appears to be confused ;-). The -00 version of this draft is from 2012, and this draft does not contain sufficient material from RFC 3748 that would raise that concern, so this comment should be ok to ignore. Thanks, --David David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 david.bl...@emc.com Mobile: +1 (978) 394-7754
RE: [abfab] Gen-ART review of draft-ietf-abfab-eapapplicability-03
I think this is ok, but my email client isn't distinguishing the new vs. old text. If it's just changes to produce this new bullet, I have a small edit: o Channel binding MUST be used for all application authentication. The EAP server MUST either require that the correct EAP lower-layer attribute or another attribute indicating the purpose of the authentication be present in the channel binding data for application authentication. MUST either require that -- MUST require that either Thanks, --David From: Joseph Salowey (jsalowey) [mailto:jsalo...@cisco.com] Sent: Wednesday, June 19, 2013 7:23 PM To: Black, David Cc: stefan.win...@restena.lu; General Area Review Team; ab...@ietf.org; ietf@ietf.org Subject: Re: [abfab] Gen-ART review of draft-ietf-abfab-eapapplicability-03 Thanks for the text, some revision to address On Jun 18, 2013, at 12:34 PM, Black, David david.bl...@emc.commailto:david.bl...@emc.com wrote: [Joe] Good points, the text can be more specific: In environments where EAP is used for purposes other than network access authentication all EAP servers MUST enforce channel bindings. For application authentication, the EAP server MUST require that the correct EAP lower-layer attribute be present in the channel binding data. For network access authentication, the EAP server MUST require that if channel bindings are present they MUST contain the correct EAP lower-layer attribute. All network access EAP peer implementations SHOULD use channel bindings including the EAP lower-layer attribute to explicitly identify the reason for authentication. Any new usage of EAP MUST use channel bindings including the EAP lower-layer attribute to prevent confusion with network access usage. This is looking good, modulo Sam's comment on EAP lower-layer vs. something else that I'll leave to you and he to sort out. I have a suggested rewrite, mostly to clarify MUST vs. SHOULD requirements for support vs. usage, and to reformat into a structured bullet list of requirements (this is not intended to change any requirements from what you wrote): In environments where EAP is used for purposes other than network access authentication: o All EAP servers and all application access EAP peers MUST support channel bindings. All network access EAP peers SHOULD support channel bindings. o Channel binding MUST be used for all application authentication. The EAP server MUST require that the correct EAP lower-layer attribute be present in the channel binding data for application authentication. o Channel binding MUST be used for all application authentication. The EAP server MUST either require that the correct EAP lower-layer attribute or another attribute indicating the purpose of the authentication be present in the channel binding data for application authentication. o Channel binding SHOULD be used for all network access authentication, and when channel binding data is present, the EAP server MUST require that it contain the correct EAP lower-layer attribute to explicitly identify the reason for authentication. o Any new usage of EAP MUST use channel bindings including the EAP lower-layer attribute to prevent confusion with network access usage. Thanks, --David -Original Message- From: Joseph Salowey (jsalowey) [mailto:jsalo...@cisco.comhttp://cisco.com] Sent: Tuesday, June 18, 2013 1:47 PM To: Black, David Cc: stefan.win...@restena.lumailto:stefan.win...@restena.lu; General Area Review Team; ab...@ietf.orgmailto:ab...@ietf.org; ietf@ietf.orgmailto:ietf@ietf.org Subject: Re: [abfab] Gen-ART review of draft-ietf-abfab-eapapplicability-03 I think we could state this a bit better as something like: In environments where EAP is used for applications authentication and network access authentication all EAP servers MUST understand channel bindings and require that application bindings MUST be present in application authentication and that application bindings MUST be absent in network authentication. All network access EAP peer implementations SHOULD support channel binding to explicitly identify the reason for authentication. Any new usage of EAP MUST support channel bindings to prevent confusion with network access usage. That text is an improvement, and it's headed in the same direction as Sam's comment - application bindings MUST be present in application authentication is a MUST use requirement, not just a MUST implement requirement. OTOH, I'm not clear on what application bindings means, as that term's not in the current draft. Specifically, I'm a bit unclear on application bindings MUST be absent in network authentication - does that mean that channel binding must be absent, or that channel binding is optional, but if channel binding is present, it MUST NOT be an application binding, whatever that is? [Joe] Good points, the text can be more specific: In environments where EAP is used for purposes other than network access authentication all EAP servers MUST enforce
Gen-ART review of draft-ietf-abfab-eapapplicability-03
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-abfab-eapapplicability-03 Reviewer: David L. Black Review Date: June 17, 2003 IETF LC End Date: June 17, 2003 Summary: This draft is on the right track but has open issues, described in the review. This draft updates the applicability statement for EAP to include usage for application layer access via EAP over GSSAPI. Additional security requirements are introduced for environments in which EAP is used for that purpose. I found one open issue, which is minor, and may be editorial Major issues: None Minor issues: One The next to last paragraph on p.3 begins with this sentence: For these reasons, channel binding MUST be implemented by peers, EAP servers and AAA servers in environments where EAP authentication is used to access application layer services. It appear that this MUST requirement applies to all uses of EAP, including network access authentication, not just application layer access authentication. If so, that's not immediately obvious from the text, and an additional sentence should be added to make this clearer. If not, the above sentence needs to exclude network access authentication from that requirement. Nits/editorial comments: The same paragraph (p.3) continues with: In addition, channel binding MUST default to being required by peers for non-network authentication. If the EAP server is aware that authentication is for something other than a network service, it too MUST default to requiring channel binding. What is meant by non-network authentication and other than a network service? If those mean other than for network access authentication as the term network access authentication is used in section 1 and RFC 3748, that meaning should be clarified. idnits 2.12.17 generated this comment: -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at http://trustee.ietf.org/license-info for more information.) idnits appears to be confused ;-). The -00 version of this draft is from 2012, and this draft does not contain sufficient material from RFC 3748 that would raise that concern, so this comment should be ok to ignore. Thanks, --David David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 david.bl...@emc.com Mobile: +1 (978) 394-7754
RE: [abfab] Gen-ART review of draft-ietf-abfab-eapapplicability-03
Sam, I was concerned that something along these lines was lurking in here :-(. I think this is the crucial running code consideration to start from: Practically speaking, it will be a while before peers implement channel binding for network access. Assuming that network access does not use channel binding, how does one avoid the proxy attack on network access authentication via application access authentication when the latter is introduced? For environments where EAP is used for network access authentication, the suggestion of a MUST use requirement for channel binding with application access authentication sounds like the right approach: If all the application access peers support channel binding, then you could potentially require the eap-lower-layer attribute or similar for application authentication and work securely in environments where peers for network access have not been updated yet. Is that plausible and reasonable in practice? This would be in addition to the MUST implement requirements for AAA servers, EAP serves and peers doing application access: I know you're correct that AAA servers and EAP servers need to implement channel binding for network access in such environments. Thanks, --David -Original Message- From: Sam Hartman [mailto:hartm...@painless-security.com] Sent: Tuesday, June 18, 2013 10:19 AM To: Black, David Cc: stefan.win...@restena.lu; jsalo...@cisco.com; General Area Review Team; ab...@ietf.org; ietf@ietf.org Subject: Re: [abfab] Gen-ART review of draft-ietf-abfab-eapapplicability-03 Black, == Black, David david.bl...@emc.com writes: Black, The next to last paragraph on p.3 begins with this sentence: Black,For these reasons, channel binding MUST be implemented by Black, peers, EAP servers and AAA servers in environments where EAP Black, authentication is used to access application layer services. Black, It appear that this MUST requirement applies to all uses Black, of EAP, including network access authentication, not just Black, application layer access authentication. If so, that's not Black, immediately obvious from the text, and an additional Black, sentence should be added to make this clearer. If not, the Black, above sentence needs to exclude network access Black, authentication from that requirement. I know you're correct that AAA servers and EAP servers need to implement channel binding for network access in such environments. I'm not sure whether peers only doing network access SHOULD implement channel binding or MUST implement channel binding. Practically speaking, it will be a while before peers implement channel binding for network access. The sorts of attacks that result without channel binding are attacks where a peer thinks it is doing network access authentication but what it's really doing is helping an attacker access an application. If all the application access peers support channel binding, then you could potentially require the eap-lower-layer attribute or similar for application authentication and work securely in environments where peers for network access have not been updated yet. It's also kind of tempting to stick our head in the sand and just add the clarification that yes, we mean network access too. --Sam
RE: [abfab] Gen-ART review of draft-ietf-abfab-eapapplicability-03
[Joe] I'm trying to get a handle on the attack mechanism here. In this attack a valid network service is trying to spoof an application service? Since it knows the MSK it can do this if the channel-binding of the lower- layer into the EAP conversation is not enforced. If the AAA server always enforces channel bindings for applications then it will catch the spoofing attempt. The reverse case may also be an issue where an application service is trying to spoof a network service. While both cases appear to be relevant, my concern started from the reverse case - here's the draft's text describing the attack: One potentially serious attack exists when channel binding is not required and EAP authentication is introduced into an existing non- network service. A device can be created that impersonates a Network Access Service to peers, but actually proxies the authentication to the new application service that accepts EAP authentications. This may decrease the security of this service even for users who previously used non-EAP means of authentication to the service. In this case, if the AAA server validates that the application channel binding is not present then it can prevent the spoofing. However the server MUST understand channel bindings even if the peers do not. I think the document did try to capture this in the following sentence: If the EAP server is aware that authentication is for something other than a network service, it too MUST default to requiring channel binding. I think we could state this a bit better as something like: In environments where EAP is used for applications authentication and network access authentication all EAP servers MUST understand channel bindings and require that application bindings MUST be present in application authentication and that application bindings MUST be absent in network authentication. All network access EAP peer implementations SHOULD support channel binding to explicitly identify the reason for authentication. Any new usage of EAP MUST support channel bindings to prevent confusion with network access usage. That text is an improvement, and it's headed in the same direction as Sam's comment - application bindings MUST be present in application authentication is a MUST use requirement, not just a MUST implement requirement. OTOH, I'm not clear on what application bindings means, as that term's not in the current draft. Specifically, I'm a bit unclear on application bindings MUST be absent in network authentication - does that mean that channel binding must be absent, or that channel binding is optional, but if channel binding is present, it MUST NOT be an application binding, whatever that is? Thanks, --David -Original Message- From: Joseph Salowey (jsalowey) [mailto:jsalo...@cisco.com] Sent: Tuesday, June 18, 2013 1:10 PM To: Sam Hartman Cc: Black, David; stefan.win...@restena.lu; General Area Review Team; ab...@ietf.org; ietf@ietf.org Subject: Re: [abfab] Gen-ART review of draft-ietf-abfab-eapapplicability-03 On Jun 18, 2013, at 7:18 AM, Sam Hartman hartm...@painless-security.com wrote: Black, == Black, David david.bl...@emc.com writes: Black, The next to last paragraph on p.3 begins with this sentence: Black,For these reasons, channel binding MUST be implemented by Black, peers, EAP servers and AAA servers in environments where EAP Black, authentication is used to access application layer services. Black, It appear that this MUST requirement applies to all uses Black, of EAP, including network access authentication, not just Black, application layer access authentication. If so, that's not Black, immediately obvious from the text, and an additional Black, sentence should be added to make this clearer. If not, the Black, above sentence needs to exclude network access Black, authentication from that requirement. I know you're correct that AAA servers and EAP servers need to implement channel binding for network access in such environments. I'm not sure whether peers only doing network access SHOULD implement channel binding or MUST implement channel binding. Practically speaking, it will be a while before peers implement channel binding for network access. The sorts of attacks that result without channel binding are attacks where a peer thinks it is doing network access authentication but what it's really doing is helping an attacker access an application. If all the application access peers support channel binding, then you could potentially require the eap-lower-layer attribute or similar for application authentication and work securely in environments where peers for network access have not been updated yet. [Joe] I'm trying to get a handle on the attack mechanism here. In this attack a valid network service is trying to spoof an application
RE: [abfab] Gen-ART review of draft-ietf-abfab-eapapplicability-03
[Joe] Good points, the text can be more specific: In environments where EAP is used for purposes other than network access authentication all EAP servers MUST enforce channel bindings. For application authentication, the EAP server MUST require that the correct EAP lower-layer attribute be present in the channel binding data. For network access authentication, the EAP server MUST require that if channel bindings are present they MUST contain the correct EAP lower-layer attribute. All network access EAP peer implementations SHOULD use channel bindings including the EAP lower-layer attribute to explicitly identify the reason for authentication. Any new usage of EAP MUST use channel bindings including the EAP lower-layer attribute to prevent confusion with network access usage. This is looking good, modulo Sam's comment on EAP lower-layer vs. something else that I'll leave to you and he to sort out. I have a suggested rewrite, mostly to clarify MUST vs. SHOULD requirements for support vs. usage, and to reformat into a structured bullet list of requirements (this is not intended to change any requirements from what you wrote): In environments where EAP is used for purposes other than network access authentication: o All EAP servers and all application access EAP peers MUST support channel bindings. All network access EAP peers SHOULD support channel bindings. o Channel binding MUST be used for all application authentication. The EAP server MUST require that the correct EAP lower-layer attribute be present in the channel binding data for application authentication. o Channel binding SHOULD be used for all network access authentication, and when channel binding data is present, the EAP server MUST require that it contain the correct EAP lower-layer attribute to explicitly identify the reason for authentication. o Any new usage of EAP MUST use channel bindings including the EAP lower-layer attribute to prevent confusion with network access usage. Thanks, --David -Original Message- From: Joseph Salowey (jsalowey) [mailto:jsalo...@cisco.com] Sent: Tuesday, June 18, 2013 1:47 PM To: Black, David Cc: stefan.win...@restena.lu; General Area Review Team; ab...@ietf.org; ietf@ietf.org Subject: Re: [abfab] Gen-ART review of draft-ietf-abfab-eapapplicability-03 I think we could state this a bit better as something like: In environments where EAP is used for applications authentication and network access authentication all EAP servers MUST understand channel bindings and require that application bindings MUST be present in application authentication and that application bindings MUST be absent in network authentication. All network access EAP peer implementations SHOULD support channel binding to explicitly identify the reason for authentication. Any new usage of EAP MUST support channel bindings to prevent confusion with network access usage. That text is an improvement, and it's headed in the same direction as Sam's comment - application bindings MUST be present in application authentication is a MUST use requirement, not just a MUST implement requirement. OTOH, I'm not clear on what application bindings means, as that term's not in the current draft. Specifically, I'm a bit unclear on application bindings MUST be absent in network authentication - does that mean that channel binding must be absent, or that channel binding is optional, but if channel binding is present, it MUST NOT be an application binding, whatever that is? [Joe] Good points, the text can be more specific: In environments where EAP is used for purposes other than network access authentication all EAP servers MUST enforce channel bindings. For application authentication, the EAP server MUST require that the correct EAP lower-layer attribute be present in the channel binding data. For network access authentication, the EAP server MUST require that if channel bindings are present they MUST contain the correct EAP lower-layer attribute. All network access EAP peer implementations SHOULD use channel bindings including the EAP lower-layer attribute to explicitly identify the reason for authentication. Any new usage of EAP MUST use channel bindings including the EAP lower-layer attribute to prevent confusion with network access usage. Does this help? Thanks, Joe
Gen-ART review of draft-eastlake-rfc5342bis-03
The -03 version of this draft resolves all of the concerns raised by the Gen-ART review of the -02 version. Unfortunately, a serious typo/thinko snuck into the -03 version (been there, done that, myself). Section 3.2 currently says: 00-42 is a protocol number under the IANA OUI (that is, 00-00-0E-00-42) to be used for documentation purposes. The parenthetical expansion of the protocol number is incorrect. The correct expansion uses -5E- instead of -0E-: 00-42 is a protocol number under the IANA OUI (that is, 00-00-5E-00-42) to be used for documentation purposes. I strongly suggest submitting a -04 version of this draft to make the necessary single character correction (e.g., as opposed to using a RFC Editor Note for that purpose). Thanks, --David -Original Message- From: Black, David Sent: Wednesday, June 05, 2013 6:13 PM To: d3e...@gmail.com; joe.ab...@icann.org; General Area Review Team Cc: Black, David; joe...@bogus.com; ietf@ietf.org Subject: Gen-ART review of draft-eastlake-rfc5342bis-02 I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-eastlake-rfc5342bis-02 Reviewer: David L. Black Review Date: June 5, 2013 IETF LC End Date: June 4, 2013 Summary: This draft is on the right track but has open issues, described in the review. This draft updates the IANA registered Ethernet parameters for IETF use, including recording values assigned for documentation. It also makes some minor changes to IANA procedures. IANA should review this entire draft, not just its IANA Considerations section; Pearl Liang appears to have done that comprehensive review for IANA. Major issues: None Minor issues: One, the IANA review also found this issue. Section 3.2 states: IANA will assign 00-00-0E-00-42 as the protocol number under the IANA OUI to be used for documentation purposes. IANA has not made this assignment, but this assignment request is not recorded in the IANA Considerations section where IANA actions are requested and recorded by IANA after they have been performed. This assignment needs to be added to the IANA Considerations section; see item 5 in the IANA review. Nits/editorial comments: Section 1: This document uses an IESG Ratification process for some assignments. This is not the same process as the IESG Approval process defined in RFC 5226. As those names could be confused by a casual reader who is not strongly familiar with IANA processes, I suggest adding a statement that the IESG Ratification process is defined in this document and is not the same as the IESG Approval process in RFC 5226. This could be added after the sentence that cites RFC 5226. Section 1.4: It would be helpful to point out that there is no OUI assigned for documentation purposes, but there are identifiers based on the IANA OUI that have been assigned for documentation purposes. In general, the use of the acronym IAB for Individual Address Block is unfortunate, but unavoidable, and this is clearly pointed out in the definition of the IAB acronym in section 1.2. Nothing can or should be done about this. idnits 2.12.17 did not find any nits. Thanks, --David David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 david.bl...@emc.com Mobile: +1 (978) 394-7754
RE: Gen-ART review of draft-eastlake-rfc5342bis-03
I strongly suggest submitting a -04 version of this draft to make the necessary single character correction (e.g., as opposed to using a RFC Editor Note for that purpose). I defer entirely to Joel Jaeggli, the sponsoring AD. I'm happy to leave that decision up to Joel. I'm concerned about readers who aren't as cognizant of and comfortable/familiar with the relationships among OUIs and the identifiers based on them as people like you and me. Thanks, --David -Original Message- From: Donald Eastlake [mailto:d3e...@gmail.com] Sent: Sunday, June 09, 2013 2:07 PM To: Black, David Cc: joe.ab...@icann.org; General Area Review Team; joe...@bogus.com; ietf@ietf.org Subject: Re: Gen-ART review of draft-eastlake-rfc5342bis-03 Hi David, On Sun, Jun 9, 2013 at 1:47 PM, Black, David david.bl...@emc.com wrote: The -03 version of this draft resolves all of the concerns raised by the Gen-ART review of the -02 version. Thanks. Unfortunately, a serious typo/thinko snuck into the -03 version (been there, done that, myself). Section 3.2 currently says: 00-42 is a protocol number under the IANA OUI (that is, 00-00-0E-00-42) to be used for documentation purposes. The parenthetical expansion of the protocol number is incorrect. The correct expansion uses -5E- instead of -0E-: My apologies, you are correct. However, I believe that, in context, the typo is pretty obvious. 00-42 is a protocol number under the IANA OUI (that is, 00-00-5E-00-42) to be used for documentation purposes. I strongly suggest submitting a -04 version of this draft to make the necessary single character correction (e.g., as opposed to using a RFC Editor Note for that purpose). I defer entirely to JoelJaeggli, the sponsoring AD. I'd be happy to submit a -04 or it seems to me it could easily be fixed with an RFC Editor Note or at AUTH48 time. (Actually, it seems likely to me that during IESG consideration, some other change will be decided on and this can be fixed at the same time.) Thanks, Donald = Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e...@gmail.com Thanks, --David -Original Message- From: Black, David Sent: Wednesday, June 05, 2013 6:13 PM To: d3e...@gmail.com; joe.ab...@icann.org; General Area Review Team Cc: Black, David; joe...@bogus.com; ietf@ietf.org Subject: Gen-ART review of draft-eastlake-rfc5342bis-02 I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-eastlake-rfc5342bis-02 Reviewer: David L. Black Review Date: June 5, 2013 IETF LC End Date: June 4, 2013 Summary: This draft is on the right track but has open issues, described in the review. This draft updates the IANA registered Ethernet parameters for IETF use, including recording values assigned for documentation. It also makes some minor changes to IANA procedures. IANA should review this entire draft, not just its IANA Considerations section; Pearl Liang appears to have done that comprehensive review for IANA. Major issues: None Minor issues: One, the IANA review also found this issue. Section 3.2 states: IANA will assign 00-00-0E-00-42 as the protocol number under the IANA OUI to be used for documentation purposes. IANA has not made this assignment, but this assignment request is not recorded in the IANA Considerations section where IANA actions are requested and recorded by IANA after they have been performed. This assignment needs to be added to the IANA Considerations section; see item 5 in the IANA review. Nits/editorial comments: Section 1: This document uses an IESG Ratification process for some assignments. This is not the same process as the IESG Approval process defined in RFC 5226. As those names could be confused by a casual reader who is not strongly familiar with IANA processes, I suggest adding a statement that the IESG Ratification process is defined in this document and is not the same as the IESG Approval process in RFC 5226. This could be added after the sentence that cites RFC 5226. Section 1.4: It would be helpful to point out that there is no OUI assigned for documentation purposes, but there are identifiers based on the IANA OUI that have been assigned for documentation purposes. In general, the use of the acronym IAB for Individual Address Block is unfortunate, but unavoidable, and this is clearly pointed out in the definition of the IAB acronym in section 1.2. Nothing can or should be done about this. idnits 2.12.17 did not find any nits. Thanks, --David
Gen-ART review of draft-eastlake-rfc5342bis-02
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-eastlake-rfc5342bis-02 Reviewer: David L. Black Review Date: June 5, 2013 IETF LC End Date: June 4, 2013 Summary: This draft is on the right track but has open issues, described in the review. This draft updates the IANA registered Ethernet parameters for IETF use, including recording values assigned for documentation. It also makes some minor changes to IANA procedures. IANA should review this entire draft, not just its IANA Considerations section; Pearl Liang appears to have done that comprehensive review for IANA. Major issues: None Minor issues: One, the IANA review also found this issue. Section 3.2 states: IANA will assign 00-00-0E-00-42 as the protocol number under the IANA OUI to be used for documentation purposes. IANA has not made this assignment, but this assignment request is not recorded in the IANA Considerations section where IANA actions are requested and recorded by IANA after they have been performed. This assignment needs to be added to the IANA Considerations section; see item 5 in the IANA review. Nits/editorial comments: Section 1: This document uses an IESG Ratification process for some assignments. This is not the same process as the IESG Approval process defined in RFC 5226. As those names could be confused by a casual reader who is not strongly familiar with IANA processes, I suggest adding a statement that the IESG Ratification process is defined in this document and is not the same as the IESG Approval process in RFC 5226. This could be added after the sentence that cites RFC 5226. Section 1.4: It would be helpful to point out that there is no OUI assigned for documentation purposes, but there are identifiers based on the IANA OUI that have been assigned for documentation purposes. In general, the use of the acronym IAB for Individual Address Block is unfortunate, but unavoidable, and this is clearly pointed out in the definition of the IAB acronym in section 1.2. Nothing can or should be done about this. idnits 2.12.17 did not find any nits. Thanks, --David David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 david.bl...@emc.com Mobile: +1 (978) 394-7754
Gen-ART review of draft-ietf-karp-crypto-key-table-07
Document: draft-ietf-karp-crypto-key-table-07 Reviewer: David L. Black Review Date: April 25, 2013 IETF LC End Date: April 29, 2013 Summary: This draft is on the right track, but has open issues described in the review. This draft describes a conceptual key database for use by protocols. It's definitely useful and valuable work, as key management is often an afterthought in protocol design, even when security functionality is actively worked on in the design process. The draft text is in good shape and reads cleanly, but the draft is short on precision in specifying a number of the fields for the database, and the IANA registries; most of the open issues are requests for the level of precision needed for interoperability and reuse of database implementation across different protocol implementations. Major issues: (Section 2) [1] LocalKeyName and PeerKeyName are strings. What character set? If Unicode (e.g., UTF-8?), add text on Unicode considerations (e.g., normalization). Finding a Unicode expert will help in getting this done quickly. I have similar concerns for other strings, and in particular, IANA should be told what a string is for any registry field that contains one. [2] I'm not sure that I understand what a KDF really is from its high level description in this draft. At the least, I'm surprised that the importance of non-invertibility of a KDF is not mentioned - beyond that, a functional description of inputs and outputs would help, including a strong recommendation to inject unpredictable nonce material. This could be handled by referencing material on what a KDF is that exists elsewhere. (Section 4) [3] It's important that this section cover all the fields involved in the database lookups in Section 3 whose format may be protocol-specific (the Direction and various time fields aren't). Protocol should be covered by the IANA registry, peers and key names are covered here, but interface appears to be missing - item (9) covers presence vs. absence of interface information, but not its format. --- Lots of issues with the IANA Considerations (Section 8) (Section 8.1.1) [5] No field format information for the fields in a registry entry. IANA should be told what formats to expect/use. [6] Protocol Specific Values is not the same as ProtocolSpecificInfo in section 2; the same name should be used, but whitespace differences are ok. [7] Should some sort of formats for Peers and Interfaces be included in registering a Protocol? If not, the lookups in section 3 may be implementation-dependent (strings that work w/one implementation may not work w/other implementations of the same protocol). The specification reference may suffice based on the requirements in section 4 for what has to be in each referenced specification. (Sections 8.2 and 8.3) [8] No registry entry content descriptions. Need to supply information on what to register and the formats of the elements of a registry entry. [9] I suggest Expert Review for these registries, not just First Come First Served, so that someone with a security clue can check that the proposed registrations are reasonable. Minor issues: [A] Overall - I would like to see a paragraph added on how this database conceptually relates to the IPsec Peer Authorization Database (PAD) - see RFC 4301, section 4.4.3. [B] (Section 2) Where is key size recorded? Is that an implicit attribute of Key? [C] (Section 3) Where does key selection occur? I would suggest that the database return all possible keys and let the protocol figure out what to use. This is particularly important for inbound traffic for obvious reasons. Nits/editorial comments: I suggest dividing section 3 into - 3.1 Outgoing Traffic - 3.2 Incoming Traffic idnits 2.12.16 found a truly trivial nit - == Line 76 has weird spacing: '...strains where...' Thanks, --David David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 david.bl...@emc.com Mobile: +1 (978) 394-7754
RE: Gen-ART review of draft-ietf-karp-crypto-key-table-07
Thanks for the quick response - most of your message looks reasonable to me. I have a few additional comments. [1] Character set for key names, etc. They are strings that can be compared using binary comparison. I agree we need to state that in the draft. That's certainly a reasonable goal, and there are plenty of examples of protocols that do that. OTOH, when the character set is Unicode, generating strings for which that binary comparison for equality works as expected has a number of subtleties when the strings are input by humans. Pete Resnick and yours truly are among the people familiar with the dragons that lurk here (and the precis WG is grappling with). We needed to add the entire complexity of making these fields be strings not integers because of some non-IETF protocols that use key names. I'm reasonably confident I can sell Pete on the concept of a binary identifier for this field from an i18n standpoint. I have no problem with the field being a binary identifier, but I think implementers should be put on notice that binary comparison of human input Unicode strings doesn't work as expected unless some things are done to make it work (this used to be known as string preparation). A warning to that effect, perhaps citing a reference for details on what can go awry, accompanied by making the protocol spec responsible for getting this right ought to suffice. [3] Protocol responsibility to specify interface format We mandate that you must be able to tie things to interface. However the format of an interface is quite specific to the routing platform in question. Ok, I suggest explaining that as part of a statement that a protocol cannot in general be expected to specify interface formats that apply across all implementations due to implementation diversity. [7] Additional format information in registry Black, [7] Should some sort of formats for Peers and Interfaces be Black, included in registering a Protocol? If not, the lookups in Black, section 3 may be implementation-dependent (strings that work Black, w/one implementation may not work w/other implementations of Black, the same protocol). The specification reference may suffice Black, based on the requirements in section 4 for what has to be in Black, each referenced specification. When you register a protocol you need to point to a specification that gives details on this sort of thing. That makes sense, and section 4's requirements on the specifications cover this area, but I thought I'd ask. [9] Registry policy As an individual, I support FCFS, because I think getting expert approval for some of the uses that have been proposed for these registries will be challenging. The two registries involved are for KDFs and cryptographic algorithm identifiers. This feels like something that the security area ought to weigh in on, as it looks like it includes the vanity crypto discussion tarpit ;-). At a minimum, I would think that there ought to be some means of prohibiting registration of a crypto algorithm like ROT13 (http://en.wikipedia.org/wiki/ROT13). Thanks, --David -Original Message- From: Sam Hartman [mailto:hartmans-i...@mit.edu] Sent: Thursday, April 25, 2013 12:47 PM To: Black, David Cc: Russ Housley; tim.p...@nist.gov; zhangdach...@huawei.com; gen- a...@ietf.org; k...@ietf.org; ietf@ietf.org; stbry...@cisco.com Subject: Re: Gen-ART review of draft-ietf-karp-crypto-key-table-07 Here are some quick initial responses to your comments. Thanks much for the review and I'll follow up with more detail in a while. Black, == Black, David david.bl...@emc.com writes: Black, Major issues: Black, (Section 2) Black, [1] LocalKeyName and PeerKeyName are strings. What Black, character set? If Unicode (e.g., UTF-8?), add text on Black, Unicode considerations (e.g., normalization). Finding a Black, Unicode expert will help in getting this done quickly. I Black, have similar concerns for other strings, and in particular, Black, IANA should be told what a string is for any registry Black, field that contains one. They are strings that can be compared using binary comparison. I agree we need to state that in the draft. Character set, to the extent it is specified will be specified by the individual protocol. In practice the protocol will say that it's an integer represented as an ASCII string. We needed to add the entire complexity of making these fields be strings not integers because of some non-IETF protocols that use key names. I'm reasonably confident I can sell Pete on the concept of a binary identifier for this field from an i18n standpoint. But issues, of length, format, etc are all specified by the protocol spec. Black, [2] I'm not sure that I understand what a KDF really is from Black, its high level description in this draft
RE: Gen-ART review of draft-ietf-savi-threat-scope-07
The -07 version of this draft resolves all of the issues raised by the Gen-ART review of the -06 version. Discussion of the review with the authors has resulted in a common understanding that there is no need for additional text on statically allowing all source addresses through all links in a set of teamed/aggregated links - that's at best nice to have for this draft, but not essential. Thanks, --David -Original Message- From: Black, David Sent: Monday, March 25, 2013 9:04 PM To: McPherson, Danny; Fred Baker; joel.halp...@ericsson.com; gen-...@ietf.org Cc: Jean-Michel Combes; Ted Lemon; s...@ietf.org; Black, David; ietf@ietf.org Subject: Gen-ART review of draft-ietf-savi-threat-scope-06 I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-savi-threat-scope-06 Reviewer: David L. Black Review Date: March 27, 2013 IESG Telechat Date: (if known) Summary: This draft is on the right track, but has open issues, described in the review. Looking at the original Gen-ART review of the -05 draft and checking the diffs between -05 and -06, the issues raised by that review have only been partially addressed: There is no discussion of link teaming or aggregation (e.g., via LACP); this may affect source address validation functionality by requiring the same validation checks on all aggregated ports. An important case to discuss is where the aggregated host links are connected to ports on different switches (e.g., in an active/passive configuration). This is partially addressed on 4.1.2 (new section in -06), but only in terms of moving validation state when something like LACP reconfigures. This has a couple of shortcomings: a) the alternative of statically allowing all source addresses through all teamed/aggregated links (decouples SAVI state from link teaming/aggregation state) should also be mentioned, and b) the new text implies that LACP is the only way to cause this situation - it's not, so LACP should be used as an example. VRRP is another example. (1) Some of the software switch implementations are single instance switches whose implementation is distributed across multiple physical servers. This results in concerns similar to the link aggregation discussion above. I don't think this has been addressed, but the notion of single-instance switches could be added to the generalization of the new text in 4.1.2. (2) Live migration of virtual machines among physical servers causes relocation of MAC addresses across switch ports. A so-called gratuitous ARP is often used to inform the network of the MAC address move; port-based source address validation information needs to move in response to such ARPs. (3) MAC address relocation is also used as a failure recovery technique; the surviving hardware element (e.g., host in a cluster) takes over the MAC addresses of the failed hardware; like the previous case, a gratuitous ARP is a common means of informing the network that the MAC address has moved, and source address validation information needs to move in response to it. Minor issues: There doesn't seem to be much discussion of dynamic network reconfiguration, which may change traffic egress points. VRRP may be a useful example to discuss beyond the typical routing protocol updates to forwarding tables. A paragraph has been added to 5.2.3 to address all three of the above concerns. I guess that's ok, but I would have liked to see some text pointing out that a MAC move can be detected by the switches and used to update SAVI state about which port(s) a MAC is accessed through. Thanks, --David -Original Message- From: Black, David Sent: Friday, May 13, 2011 1:03 AM To: McPherson, Danny; Fred Baker; joel.halp...@ericsson.com; gen- a...@ietf.org Cc: Black, David; Christian Vogt; Jean-Michel Combes; Jari Arkko; s...@ietf.org Subject: Gen-ART review of draft-ietf-savi-threat-scope-05 I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-savi-threat-scope-05 Reviewer: David L. Black Review Date: 12 May 2011 IETF LC End Date: 18 May 2011 Summary: This draft is on the right track, but has open issues, described in the review. This draft discusses the threats and deployment environment for IP source address validation with particular attention to finer-grain validation that could be used within a network to validate IP addresses closer to the sources of network
RE: [savi] Gen-ART review of draft-ietf-savi-threat-scope-06
Joel, Yes, I think you do have the right end of the question, and that new text looks ok, as the previous sentence introduces the gratuitous ARP. To summarize, we've decided to address two of the three concerns from the review of -06. The third concern that will not be addressed is: a) the alternative of statically allowing all source addresses through all teamed/aggregated links (decouples SAVI state from link teaming/aggregation state) should also be mentioned, I'm satisfied with this outcome. Thanks, --David -Original Message- From: Joel M. Halpern [mailto:j...@joelhalpern.com] Sent: Friday, March 29, 2013 6:08 PM To: Ted Lemon Cc: Black, David; McPherson, Danny; s...@ietf.org; ietf@ietf.org; gen- a...@ietf.org; Jean-Michel Combes; joel.halp...@ericsson.com Subject: Re: [savi] Gen-ART review of draft-ietf-savi-threat-scope-06 I have a draft version with this correction. David, would adding: When such a move is done without changing the MAC address, the SAVI switches will need to update their state. While the ARP may be helpful, traffic detection, switch based neighbor solicitation, interaction with orchestration system, or other means may be used. to the end of 5.2.3 address your concern? I am not sure whether I have the right end of the question here, given that SAVI can not create new protocol. Yours, Joel On 3/27/2013 10:56 PM, Ted Lemon wrote: On Mar 27, 2013, at 12:45 PM, Joel Halpern Direct jmh.dir...@joelhalpern.com wrote: Then it will be done. I will wait for the AD to decide what other changes are needed, and then will either make this change or include it in an RFC Editor note. Old: If the bridging topologies which connects the switches changes, or if LACP [IEEE802.3ad] changes which links are used to deliver traffic, the switch may need to move the SAVI state to a different port, are the state may need to be moved or reestablished on a different switch. New: If the bridging topologies which connects the switches changes, or if LACP [IEEE802.3ad], VRRP, or other link management operations, change which links are used to deliver traffic, the switch may need to move the SAVI state to a different port, are the state may need to be moved or reestablished on a different switch. I think you probably meant or, not are, in the second word of the second-to-last line of the new text. As far as I am concerned, given that David is happy with your recent change, I'm happy with it too. However, since you are asking, if you were willing to also accommodate David's other request (see below) by adding some text to the document in section 5, that would be an added bonus: A paragraph has been added to 5.2.3 to address all three of the above concerns. I guess that's ok, but I would have liked to see some text pointing out that a MAC move can be detected by the switches and used to update SAVI state about which port(s) a MAC is accessed through. So if you can do this, it would be much appreciated; if you can't do it, I think the document is valuable enough to move forward without this additional work.
Gen-ART review of draft-ietf-pkix-rfc2560bis-16
The -16 version of this draft resolves all of the concerns raised by the Gen-ART review of the -15 version. Thanks, --David -Original Message- From: Black, David Sent: Monday, March 25, 2013 8:26 PM To: s...@aaa-sec.com; mmy...@fastq.com; ambar...@gmail.com; slava.galpe...@gmail.com; cad...@eecs.uottawa.ca; gen-...@ietf.org Cc: Black, David; p...@ietf.org; Sean Turner; ietf@ietf.org Subject: Gen-ART review of draft-ietf-pkix-rfc2560bis-15 Authors, I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-pkix-rfc2560bis-15 Reviewer: David L. Black Review Date: March 25, 2013 IETF LC End Date: March 27, 2013 Summary: This draft is on the right track but has open issues, described in the review. This draft updates the OCSP protocol for obtaining certificate status with some minor extensions. Because this is a bis draft, I reviewed the diffs against RFC 2560. I did not check the ASN.1. I also did not see a writeup for this draft in the data tracker, and so will rely on the document shepherd to ensure that the ASN.1 has been checked when the writeup is prepared. I found five open issues, all of which are minor, plus one idnits item that is probably ok, but should be double-checked. Minor issues: [1] Section 2.2: NOTE: The revoked state for known non-issued certificate serial numbers is allowed in order to reduce the risk of relying parties using CRLs as a fall back mechanism, which would be considerably higher if an unknown response was returned. Given this explanation, I'm surprised that the use of revoked instead of unknown for a known non-issued certificate is a MAY requirement and not a SHOULD requirement. Why is that the case? It appears that the reason is that the use of revoked in this situation may be dangerous when serial numbers can be predicted for certificates that will be issued in the future. If that's what's going on, this concern is already explained in the security considerations section, but it should also be mentioned here for completeness. [2] Section 4.2.2.2: The key that signs a certificate's status information need not be the same key that signed the certificate. It is necessary however to ensure that the entity signing this information is authorized to do so. Therefore, a certificate's issuer MAY either sign the OCSP responses itself or it MAY explicitly designate this authority to another entity. The two instances of MAY in the above text were both MUST in RFC 2560. The RFC 2560 text construction of MUST or MUST is a bit odd, but the two MAYs in this draft are even worse, as they allow MAY do something else entirely, despite being enclosed in an either-or construct. I strongly suspect that the latter was not intended, so the following would be clearer: The key that signs a certificate's status information need not be the same key that signed the certificate. It is necessary however to ensure that the entity signing this information is authorized to do so. Therefore, a certificate's issuer MUST do one of the following: - sign the OCSP responses itself, or - explicitly designate this authority to another entity. [3] Section 4.3: Is the SHOULD requirement still appropriate for the DSA with SHA-1 combo (vs. a MAY requirement)? This requirement was a MUST in RFC 2560, but I wonder about actual usage of DSA in practice. [4] Section 5, last paragraph: Responding a revoked state to certificate that has never been issued may enable someone to obtain a revocation response for a certificate that is not yet issued, but soon will be issued, if the CA issues certificates using sequential certificate serial number assignment. The above text after starting with the if is too narrow - it should say: if the certificate serial number of the certificate that will be issued can be predicted or guessed by the requester. Such prediction is easy for a CA that issues certificates using sequential certificate serial number assignment. There's also a nit in original text - its first line should be: Responding with a revoked state for a certificate that has never been [5] Section 5.1.1: In archival applications it is quite possible that an OCSP responder might be asked to report the validity of a certificate on a date in the distant past. Such a certificate might employ a signing method that is no longer considered acceptably secure. In such circumstances the responder MUST NOT generate a signature using a signing mechanism
RE: Gen-ART review of draft-ietf-pkix-rfc2560bis-15
Stefan, Is this important enough to do that? IMHO, yes - the running code aspects of existing responder behavior/limitations are definitely important enough for an RFC like this that revises a protocol spec, and the alternatives to revoked feel like an important complement to those aspects (discussion what to do instead when responder behavior/limitations are encountered). I appreciate the level of work that may be involved in capturing this, as I've had my share of contentious discussions in WGs that I chair - FWIW, I'm currently chairing my 4th and 5th WGs. OTOH, when a WG has put that much time/effort into reaching a (compromise) decision, it really is valuable to record why the decision was reached to avoid recovering that ground in the future and (specific to this situation) to give implementers some more context/information on how the protocol is likely to work in practice. Thanks, --David -Original Message- From: Stefan Santesson [mailto:ste...@aaa-sec.com] Sent: Wednesday, March 27, 2013 11:38 AM To: Black, David; s...@aaa-sec.com; mmy...@fastq.com; ambar...@gmail.com; slava.galpe...@gmail.com; cad...@eecs.uottawa.ca; gen-...@ietf.org Cc: p...@ietf.org; Sean Turner; ietf@ietf.org Subject: Re: Gen-ART review of draft-ietf-pkix-rfc2560bis-15 I could. My worry is just that this is such a contentious subject and it took us x hundreds of emails to reach this state, that if I add more explanations, people will start disagreeing with it and that we end up in a long debate on how to correctly express this. Is this important enough to do that? /Stefan On 3/27/13 3:30 PM, Black, David david.bl...@emc.com wrote: Hi Stefan, Does this answer your question? Yes, please add some of that explanation to the next version of the draft ;-). Coverage of existing responder behavior/limitations (important running code concerns, IMHO) and alternatives to using revoked (have a number of tools to prevent the client from accepting a bad certificate) seem particularly relevant. Thanks, --David -Original Message- From: Stefan Santesson [mailto:ste...@aaa-sec.com] Sent: Wednesday, March 27, 2013 7:44 AM To: Black, David; s...@aaa-sec.com; mmy...@fastq.com; ambar...@gmail.com; slava.galpe...@gmail.com; cad...@eecs.uottawa.ca; gen-...@ietf.org Cc: p...@ietf.org; Sean Turner; ietf@ietf.org Subject: Re: Gen-ART review of draft-ietf-pkix-rfc2560bis-15 Hi David, Yes I missed to respond to that aspect. This is a bit complicated, but we have a large legacy to take into account where some responders implements just RFC 2560, while some deliver pre-generated responses according to RFC 5019 (Light-weight OCSP). LW responders are not capable of producing a signed response at the time of responding and in case such responder finds a request for a certificate where no pre-produced response exists, it will reply with an unsigned error response unauthorized, which also is a legitimate way to respond. So the actual OCSP responder may actually know that the certificate was never issued, but since it delivers pre-produced responder through a CDN, it can not provide a revoked response in real time. So the major aim with the current writing is to declare that the revoked response is a MAY because there are other valid alternatives. We also want to avoid putting down a SHOULD respond revoked if a certificate is known to be not-issued, because that would require us to define what known to be non-issued actually means. And that could be quite tricky as OCSP responders by no means are required to have this knowledge. The OCSP responder simply have a number of tools to prevent the client from accepting a bad certificate. This update of OCSP simply allows responders to use the revoked response as a preventive measure, without mandating it. This is also related to activities in the CA Browser Forum where they put down requirements on responders complying with CAB rules to not respond good to certificates that were never issued. With this update in OCSP, they can now mandate in their policies both the fact that their responders MUST know if a certificate was never issued and MUST respond revoked. So we allow other communities to raise the bar even if the base standard defines the response as optional. In theory we could possibly say that responding revoked is optional, but if you choose between revoked and unknown then you SHOULD favour revoked over unknown. But such nested requirements just feels bad and impossible to test compliance against. I'd much rather just leave it optional. I think the Note gives a clear recommendation on this and the rationale without spelling it out as a requirement. Does this answer your question? On 3/27/13 12:51 AM, Black, David david.bl...@emc.com wrote: Hi Stefan, This looks good - thank you for the prompt response
RE: [savi] Gen-ART review of draft-ietf-savi-threat-scope-06
That would do nicely. Thanks, --David -Original Message- From: Joel M. Halpern [mailto:j...@joelhalpern.com] Sent: Wednesday, March 27, 2013 12:30 PM To: Black, David Cc: Ted Lemon; McPherson, Danny; s...@ietf.org; ietf@ietf.org; gen- a...@ietf.org; Jean-Michel Combes; joel.halp...@ericsson.com Subject: Re: [savi] Gen-ART review of draft-ietf-savi-threat-scope-06 Would it suffice to replace Old: If the bridging topologies which connects the switches changes, or if LACP [IEEE802.3ad] changes which links are used to deliver traffic, the switch may need to move the SAVI state to a different port, are the state may need to be moved or reestablished on a different switch. New: If the bridging topologies which connects the switches changes, or if LACP [IEEE802.3ad], VRRP, or other link management operations, change which links are used to deliver traffic, the switch may need to move the SAVI state to a different port, are the state may need to be moved or reestablished on a different switch. ? Proposed changes on the second - fourth lines above. Yours, Joel On 3/26/2013 7:45 PM, Black, David wrote: Ted, Remembering that this is an informational draft, which does a pretty good job of informing the reader about the problem space, is it your opinion that the issues you have raised _must_ be addressed before the document is published, or do you think the document is still valuable even if no further text is added to address your concern? At a minimum, in section 4.1.2, this should be addressed: b) the new text implies that LACP is the only way to cause this situation - it's not, so LACP should be used as an example. I'm not sure I've seen Fred's response, but that change would suffice. An RFC Editor note should suffice. Thanks, --David -Original Message- From: Ted Lemon [mailto:ted.le...@nominum.com] Sent: Monday, March 25, 2013 9:38 PM To: Black, David Cc: McPherson, Danny; Fred Baker; joel.halp...@ericsson.com; gen- a...@ietf.org; Jean-Michel Combes; s...@ietf.org; ietf@ietf.org Subject: Re: Gen-ART review of draft-ietf-savi-threat-scope-06 On Mar 25, 2013, at 9:04 PM, Black, David david.bl...@emc.com wrote: Summary: This draft is on the right track, but has open issues, described in the review. While I identified the same issue you did with switching systems that do link aggregation and other magic, I think that the document is useful whether this is fixed or not. It's true that it doesn't have a full section that talks specifically about this problem, but I think it's unlikely that the authors are going to add one-when I mentioned it to Joel, he didn't express excitement at the prospect. I think Fred's response, while a little salty, accurately represents the situation: the working group produced this document, the document does what it's supposed to do, one could continue to polish it indefinitely, but then the document would never get published. Remembering that this is an informational draft, which does a pretty good job of informing the reader about the problem space, is it your opinion that the issues you have raised _must_ be addressed before the document is published, or do you think the document is still valuable even if no further text is added to address your concern? ___ savi mailing list s...@ietf.org https://www.ietf.org/mailman/listinfo/savi
RE: Gen-ART review of draft-ietf-pkix-rfc2560bis-15
Does this solve you issue. I think this is as far as dare to go without risking a heated debate. Yes, that suffices for me - it provides a cogent explanation of why revoked is optional, and the existing text on CRLs as a fallback mechanism suffices to illuminate a likely consequence of not using revoked. Thank you, --David -Original Message- From: Carlisle Adams [mailto:cad...@eecs.uottawa.ca] Sent: Thursday, March 28, 2013 9:57 AM To: 'Stefan Santesson'; Black, David; s...@aaa-sec.com; mmy...@fastq.com; ambar...@gmail.com; slava.galpe...@gmail.com; gen-...@ietf.org Cc: p...@ietf.org; 'Sean Turner'; ietf@ietf.org Subject: RE: Gen-ART review of draft-ietf-pkix-rfc2560bis-15 Hi, This wording sounds fine to me. Thanks Stefan! Carlisle. -Original Message- From: Stefan Santesson [mailto:ste...@aaa-sec.com] Sent: March-28-13 6:34 AM To: Black, David; s...@aaa-sec.com; mmy...@fastq.com; ambar...@gmail.com; slava.galpe...@gmail.com; cad...@eecs.uottawa.ca; gen-...@ietf.org Cc: p...@ietf.org; Sean Turner; ietf@ietf.org Subject: Re: Gen-ART review of draft-ietf-pkix-rfc2560bis-15 I have given this a go by expanding the note as follows: NOTE: The revoked state for known non-issued certificate serial numbers is allowed in order to reduce the risk of relying parties using CRLs as a fall back mechanism, which would be considerably higher if an unknown response was returned. The revoked status is still optional in this context in order to maintain backwards compatibility with deployments of RFC 2560. For example, the responder may not have any knowledge about whether a requested serial number has been assigned to any issued certificate, or the responder may provide pre produced responses in accordance with RFC 5019 and, for that reason, is not capable of providing a signed response for all non-issued certificate serial numbers. Does this solve you issue. I think this is as far as dare to go without risking a heated debate. /Stefan On 3/27/13 5:08 PM, Black, David david.bl...@emc.com wrote: Stefan, Is this important enough to do that? IMHO, yes - the running code aspects of existing responder behavior/limitations are definitely important enough for an RFC like this that revises a protocol spec, and the alternatives to revoked feel like an important complement to those aspects (discussion what to do instead when responder behavior/limitations are encountered). I appreciate the level of work that may be involved in capturing this, as I've had my share of contentious discussions in WGs that I chair - FWIW, I'm currently chairing my 4th and 5th WGs. OTOH, when a WG has put that much time/effort into reaching a (compromise) decision, it really is valuable to record why the decision was reached to avoid recovering that ground in the future and (specific to this situation) to give implementers some more context/information on how the protocol is likely to work in practice. Thanks, --David -Original Message- From: Stefan Santesson [mailto:ste...@aaa-sec.com] Sent: Wednesday, March 27, 2013 11:38 AM To: Black, David; s...@aaa-sec.com; mmy...@fastq.com; ambar...@gmail.com; slava.galpe...@gmail.com; cad...@eecs.uottawa.ca; gen-...@ietf.org Cc: p...@ietf.org; Sean Turner; ietf@ietf.org Subject: Re: Gen-ART review of draft-ietf-pkix-rfc2560bis-15 I could. My worry is just that this is such a contentious subject and it took us x hundreds of emails to reach this state, that if I add more explanations, people will start disagreeing with it and that we end up in a long debate on how to correctly express this. Is this important enough to do that? /Stefan On 3/27/13 3:30 PM, Black, David david.bl...@emc.com wrote: Hi Stefan, Does this answer your question? Yes, please add some of that explanation to the next version of the draft ;-). Coverage of existing responder behavior/limitations (important running code concerns, IMHO) and alternatives to using revoked (have a number of tools to prevent the client from accepting a bad certificate) seem particularly relevant. Thanks, --David -Original Message- From: Stefan Santesson [mailto:ste...@aaa-sec.com] Sent: Wednesday, March 27, 2013 7:44 AM To: Black, David; s...@aaa-sec.com; mmy...@fastq.com; ambar...@gmail.com; slava.galpe...@gmail.com; cad...@eecs.uottawa.ca; gen-...@ietf.org Cc: p...@ietf.org; Sean Turner; ietf@ietf.org Subject: Re: Gen-ART review of draft-ietf-pkix-rfc2560bis-15 Hi David, Yes I missed to respond to that aspect. This is a bit complicated, but we have a large legacy to take into account where some responders implements just RFC 2560, while some deliver pre-generated responses according to RFC 5019 (Light-weight OCSP). LW responders
RE: Gen-ART review of draft-ietf-savi-threat-scope-06
Ted, Remembering that this is an informational draft, which does a pretty good job of informing the reader about the problem space, is it your opinion that the issues you have raised _must_ be addressed before the document is published, or do you think the document is still valuable even if no further text is added to address your concern? At a minimum, in section 4.1.2, this should be addressed: b) the new text implies that LACP is the only way to cause this situation - it's not, so LACP should be used as an example. I'm not sure I've seen Fred's response, but that change would suffice. An RFC Editor note should suffice. Thanks, --David -Original Message- From: Ted Lemon [mailto:ted.le...@nominum.com] Sent: Monday, March 25, 2013 9:38 PM To: Black, David Cc: McPherson, Danny; Fred Baker; joel.halp...@ericsson.com; gen-...@ietf.org; Jean-Michel Combes; s...@ietf.org; ietf@ietf.org Subject: Re: Gen-ART review of draft-ietf-savi-threat-scope-06 On Mar 25, 2013, at 9:04 PM, Black, David david.bl...@emc.com wrote: Summary: This draft is on the right track, but has open issues, described in the review. While I identified the same issue you did with switching systems that do link aggregation and other magic, I think that the document is useful whether this is fixed or not. It's true that it doesn't have a full section that talks specifically about this problem, but I think it's unlikely that the authors are going to add one-when I mentioned it to Joel, he didn't express excitement at the prospect. I think Fred's response, while a little salty, accurately represents the situation: the working group produced this document, the document does what it's supposed to do, one could continue to polish it indefinitely, but then the document would never get published. Remembering that this is an informational draft, which does a pretty good job of informing the reader about the problem space, is it your opinion that the issues you have raised _must_ be addressed before the document is published, or do you think the document is still valuable even if no further text is added to address your concern?
RE: Gen-ART review of draft-ietf-pkix-rfc2560bis-15
Hi Stefan, This looks good - thank you for the prompt response. It looks like my speculation on item [1] was wrong, so could you respond to the question below, please?: [1] Section 2.2: NOTE: The revoked state for known non-issued certificate serial numbers is allowed in order to reduce the risk of relying parties using CRLs as a fall back mechanism, which would be considerably higher if an unknown response was returned. Given this explanation, I'm surprised that the use of revoked instead of unknown for a known non-issued certificate is a MAY requirement and not a SHOULD requirement. Why is that the case? -- Beyond that, the proposed actions (or proposed non-actions) on items [2]-[5] are fine with me, Sean's taken care of the author permissions item from idnits, and I assume someone has or will check the ASN.1 . Thanks, --David -Original Message- From: Stefan Santesson [mailto:ste...@aaa-sec.com] Sent: Monday, March 25, 2013 10:21 PM To: Black, David; s...@aaa-sec.com; mmy...@fastq.com; ambar...@gmail.com; slava.galpe...@gmail.com; cad...@eecs.uottawa.ca; gen-...@ietf.org Cc: p...@ietf.org; Sean Turner; ietf@ietf.org Subject: Re: Gen-ART review of draft-ietf-pkix-rfc2560bis-15 Hi David, Thanks for the review. My reply in line. On 3/26/13 1:25 AM, Black, David david.bl...@emc.com wrote: Authors, I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-pkix-rfc2560bis-15 Reviewer: David L. Black Review Date: March 25, 2013 IETF LC End Date: March 27, 2013 Summary: This draft is on the right track but has open issues, described in the review. This draft updates the OCSP protocol for obtaining certificate status with some minor extensions. Because this is a bis draft, I reviewed the diffs against RFC 2560. I did not check the ASN.1. I also did not see a writeup for this draft in the data tracker, and so will rely on the document shepherd to ensure that the ASN.1 has been checked when the writeup is prepared. I found five open issues, all of which are minor, plus one idnits item that is probably ok, but should be double-checked. Minor issues: [1] Section 2.2: NOTE: The revoked state for known non-issued certificate serial numbers is allowed in order to reduce the risk of relying parties using CRLs as a fall back mechanism, which would be considerably higher if an unknown response was returned. Given this explanation, I'm surprised that the use of revoked instead of unknown for a known non-issued certificate is a MAY requirement and not a SHOULD requirement. Why is that the case? It appears that the reason is that the use of revoked in this situation may be dangerous when serial numbers can be predicted for certificates that will be issued in the future. If that's what's going on, this concern is already explained in the security considerations section, but it should also be mentioned here for completeness. No, this is not the main reason. The main reason is the one stated as a Note: in this section: NOTE: The revoked state for known non-issued certificate serial numbers is allowed in order to reduce the risk of relying parties using CRLs as a fall back mechanism, which would be considerably higher if an unknown response was returned. [2] Section 4.2.2.2: The key that signs a certificate's status information need not be the same key that signed the certificate. It is necessary however to ensure that the entity signing this information is authorized to do so. Therefore, a certificate's issuer MAY either sign the OCSP responses itself or it MAY explicitly designate this authority to another entity. The two instances of MAY in the above text were both MUST in RFC 2560. The RFC 2560 text construction of MUST or MUST is a bit odd, but the two MAYs in this draft are even worse, as they allow MAY do something else entirely, despite being enclosed in an either-or construct. I strongly suspect that the latter was not intended, so the following would be clearer: The key that signs a certificate's status information need not be the same key that signed the certificate. It is necessary however to ensure that the entity signing this information is authorized to do so. Therefore, a certificate's issuer MUST do one of the following: - sign the OCSP responses itself, or - explicitly designate this authority to another entity. I Agree. I will adopt your text. [3] Section 4.3: Is the SHOULD requirement still appropriate for the DSA with SHA-1 combo (vs. a MAY requirement
RE: Gen-ART review of draft-ietf-pkix-rfc2560bis-15
Hi Stefan, Does this answer your question? Yes, please add some of that explanation to the next version of the draft ;-). Coverage of existing responder behavior/limitations (important running code concerns, IMHO) and alternatives to using revoked (have a number of tools to prevent the client from accepting a bad certificate) seem particularly relevant. Thanks, --David -Original Message- From: Stefan Santesson [mailto:ste...@aaa-sec.com] Sent: Wednesday, March 27, 2013 7:44 AM To: Black, David; s...@aaa-sec.com; mmy...@fastq.com; ambar...@gmail.com; slava.galpe...@gmail.com; cad...@eecs.uottawa.ca; gen-...@ietf.org Cc: p...@ietf.org; Sean Turner; ietf@ietf.org Subject: Re: Gen-ART review of draft-ietf-pkix-rfc2560bis-15 Hi David, Yes I missed to respond to that aspect. This is a bit complicated, but we have a large legacy to take into account where some responders implements just RFC 2560, while some deliver pre-generated responses according to RFC 5019 (Light-weight OCSP). LW responders are not capable of producing a signed response at the time of responding and in case such responder finds a request for a certificate where no pre-produced response exists, it will reply with an unsigned error response unauthorized, which also is a legitimate way to respond. So the actual OCSP responder may actually know that the certificate was never issued, but since it delivers pre-produced responder through a CDN, it can not provide a revoked response in real time. So the major aim with the current writing is to declare that the revoked response is a MAY because there are other valid alternatives. We also want to avoid putting down a SHOULD respond revoked if a certificate is known to be not-issued, because that would require us to define what known to be non-issued actually means. And that could be quite tricky as OCSP responders by no means are required to have this knowledge. The OCSP responder simply have a number of tools to prevent the client from accepting a bad certificate. This update of OCSP simply allows responders to use the revoked response as a preventive measure, without mandating it. This is also related to activities in the CA Browser Forum where they put down requirements on responders complying with CAB rules to not respond good to certificates that were never issued. With this update in OCSP, they can now mandate in their policies both the fact that their responders MUST know if a certificate was never issued and MUST respond revoked. So we allow other communities to raise the bar even if the base standard defines the response as optional. In theory we could possibly say that responding revoked is optional, but if you choose between revoked and unknown then you SHOULD favour revoked over unknown. But such nested requirements just feels bad and impossible to test compliance against. I'd much rather just leave it optional. I think the Note gives a clear recommendation on this and the rationale without spelling it out as a requirement. Does this answer your question? On 3/27/13 12:51 AM, Black, David david.bl...@emc.com wrote: Hi Stefan, This looks good - thank you for the prompt response. It looks like my speculation on item [1] was wrong, so could you respond to the question below, please?: [1] Section 2.2: NOTE: The revoked state for known non-issued certificate serial numbers is allowed in order to reduce the risk of relying parties using CRLs as a fall back mechanism, which would be considerably higher if an unknown response was returned. Given this explanation, I'm surprised that the use of revoked instead of unknown for a known non-issued certificate is a MAY requirement and not a SHOULD requirement. Why is that the case? -- Beyond that, the proposed actions (or proposed non-actions) on items [2]-[5] are fine with me, Sean's taken care of the author permissions item from idnits, and I assume someone has or will check the ASN.1 . Thanks, --David -Original Message- From: Stefan Santesson [mailto:ste...@aaa-sec.com] Sent: Monday, March 25, 2013 10:21 PM To: Black, David; s...@aaa-sec.com; mmy...@fastq.com; ambar...@gmail.com; slava.galpe...@gmail.com; cad...@eecs.uottawa.ca; gen-...@ietf.org Cc: p...@ietf.org; Sean Turner; ietf@ietf.org Subject: Re: Gen-ART review of draft-ietf-pkix-rfc2560bis-15 Hi David, Thanks for the review. My reply in line. On 3/26/13 1:25 AM, Black, David david.bl...@emc.com wrote: Authors, I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-pkix-rfc2560bis-15 Reviewer: David L. Black Review Date: March 25, 2013 IETF LC
Gen-ART review of draft-ietf-pkix-rfc2560bis-15
Authors, I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-pkix-rfc2560bis-15 Reviewer: David L. Black Review Date: March 25, 2013 IETF LC End Date: March 27, 2013 Summary: This draft is on the right track but has open issues, described in the review. This draft updates the OCSP protocol for obtaining certificate status with some minor extensions. Because this is a bis draft, I reviewed the diffs against RFC 2560. I did not check the ASN.1. I also did not see a writeup for this draft in the data tracker, and so will rely on the document shepherd to ensure that the ASN.1 has been checked when the writeup is prepared. I found five open issues, all of which are minor, plus one idnits item that is probably ok, but should be double-checked. Minor issues: [1] Section 2.2: NOTE: The revoked state for known non-issued certificate serial numbers is allowed in order to reduce the risk of relying parties using CRLs as a fall back mechanism, which would be considerably higher if an unknown response was returned. Given this explanation, I'm surprised that the use of revoked instead of unknown for a known non-issued certificate is a MAY requirement and not a SHOULD requirement. Why is that the case? It appears that the reason is that the use of revoked in this situation may be dangerous when serial numbers can be predicted for certificates that will be issued in the future. If that's what's going on, this concern is already explained in the security considerations section, but it should also be mentioned here for completeness. [2] Section 4.2.2.2: The key that signs a certificate's status information need not be the same key that signed the certificate. It is necessary however to ensure that the entity signing this information is authorized to do so. Therefore, a certificate's issuer MAY either sign the OCSP responses itself or it MAY explicitly designate this authority to another entity. The two instances of MAY in the above text were both MUST in RFC 2560. The RFC 2560 text construction of MUST or MUST is a bit odd, but the two MAYs in this draft are even worse, as they allow MAY do something else entirely, despite being enclosed in an either-or construct. I strongly suspect that the latter was not intended, so the following would be clearer: The key that signs a certificate's status information need not be the same key that signed the certificate. It is necessary however to ensure that the entity signing this information is authorized to do so. Therefore, a certificate's issuer MUST do one of the following: - sign the OCSP responses itself, or - explicitly designate this authority to another entity. [3] Section 4.3: Is the SHOULD requirement still appropriate for the DSA with SHA-1 combo (vs. a MAY requirement)? This requirement was a MUST in RFC 2560, but I wonder about actual usage of DSA in practice. [4] Section 5, last paragraph: Responding a revoked state to certificate that has never been issued may enable someone to obtain a revocation response for a certificate that is not yet issued, but soon will be issued, if the CA issues certificates using sequential certificate serial number assignment. The above text after starting with the if is too narrow - it should say: if the certificate serial number of the certificate that will be issued can be predicted or guessed by the requester. Such prediction is easy for a CA that issues certificates using sequential certificate serial number assignment. There's also a nit in original text - its first line should be: Responding with a revoked state for a certificate that has never been [5] Section 5.1.1: In archival applications it is quite possible that an OCSP responder might be asked to report the validity of a certificate on a date in the distant past. Such a certificate might employ a signing method that is no longer considered acceptably secure. In such circumstances the responder MUST NOT generate a signature using a signing mechanism that is not considered acceptably secure. This could use an additional warning that certificate archival should not rely solely on signatures in archived certificates for ensuring the validity and integrity of the archived certificates because the signature algorithm(s) may transition to no longer being considered acceptably secure at some point after the certificates are archived. Nits: idnits 2.12.15 said: -- The document seems to
Gen-ART review of draft-ietf-savi-threat-scope-06
I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-savi-threat-scope-06 Reviewer: David L. Black Review Date: March 27, 2013 IESG Telechat Date: (if known) Summary: This draft is on the right track, but has open issues, described in the review. Looking at the original Gen-ART review of the -05 draft and checking the diffs between -05 and -06, the issues raised by that review have only been partially addressed: There is no discussion of link teaming or aggregation (e.g., via LACP); this may affect source address validation functionality by requiring the same validation checks on all aggregated ports. An important case to discuss is where the aggregated host links are connected to ports on different switches (e.g., in an active/passive configuration). This is partially addressed on 4.1.2 (new section in -06), but only in terms of moving validation state when something like LACP reconfigures. This has a couple of shortcomings: a) the alternative of statically allowing all source addresses through all teamed/aggregated links (decouples SAVI state from link teaming/aggregation state) should also be mentioned, and b) the new text implies that LACP is the only way to cause this situation - it's not, so LACP should be used as an example. VRRP is another example. (1) Some of the software switch implementations are single instance switches whose implementation is distributed across multiple physical servers. This results in concerns similar to the link aggregation discussion above. I don't think this has been addressed, but the notion of single-instance switches could be added to the generalization of the new text in 4.1.2. (2) Live migration of virtual machines among physical servers causes relocation of MAC addresses across switch ports. A so-called gratuitous ARP is often used to inform the network of the MAC address move; port-based source address validation information needs to move in response to such ARPs. (3) MAC address relocation is also used as a failure recovery technique; the surviving hardware element (e.g., host in a cluster) takes over the MAC addresses of the failed hardware; like the previous case, a gratuitous ARP is a common means of informing the network that the MAC address has moved, and source address validation information needs to move in response to it. Minor issues: There doesn't seem to be much discussion of dynamic network reconfiguration, which may change traffic egress points. VRRP may be a useful example to discuss beyond the typical routing protocol updates to forwarding tables. A paragraph has been added to 5.2.3 to address all three of the above concerns. I guess that's ok, but I would have liked to see some text pointing out that a MAC move can be detected by the switches and used to update SAVI state about which port(s) a MAC is accessed through. Thanks, --David -Original Message- From: Black, David Sent: Friday, May 13, 2011 1:03 AM To: McPherson, Danny; Fred Baker; joel.halp...@ericsson.com; gen-...@ietf.org Cc: Black, David; Christian Vogt; Jean-Michel Combes; Jari Arkko; s...@ietf.org Subject: Gen-ART review of draft-ietf-savi-threat-scope-05 I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-savi-threat-scope-05 Reviewer: David L. Black Review Date: 12 May 2011 IETF LC End Date: 18 May 2011 Summary: This draft is on the right track, but has open issues, described in the review. This draft discusses the threats and deployment environment for IP source address validation with particular attention to finer-grain validation that could be used within a network to validate IP addresses closer to the sources of network traffic than ingress to an ISP's network. Major issues: There is no discussion of link teaming or aggregation (e.g., via LACP); this may affect source address validation functionality by requiring the same validation checks on all aggregated ports. An important case to discuss is where the aggregated host links are connected to ports on different switches (e.g., in an active/passive configuration). The discussion of multi-instance hosts in section 5.2.3 is incomplete in several important aspects: (1) Some of the software switch implementations are single instance switches whose implementation is distributed across multiple physical servers. This results in concerns similar to the link aggregation discussion above. (2) Live migration of virtual machines among physical
RE: Gen-ART review of draft-ietf-savi-threat-scope-06
Review Date: March 27, 2013 Copy/paste glitch - that should be March 25 for obvious reasons ... Thanks, --David -Original Message- From: Black, David Sent: Monday, March 25, 2013 9:04 PM To: McPherson, Danny; Fred Baker; joel.halp...@ericsson.com; gen-...@ietf.org Cc: Jean-Michel Combes; Ted Lemon; s...@ietf.org; Black, David; ietf@ietf.org Subject: Gen-ART review of draft-ietf-savi-threat-scope-06 I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-savi-threat-scope-06 Reviewer: David L. Black Review Date: March 27, 2013 IESG Telechat Date: (if known) Summary: This draft is on the right track, but has open issues, described in the review. Looking at the original Gen-ART review of the -05 draft and checking the diffs between -05 and -06, the issues raised by that review have only been partially addressed: There is no discussion of link teaming or aggregation (e.g., via LACP); this may affect source address validation functionality by requiring the same validation checks on all aggregated ports. An important case to discuss is where the aggregated host links are connected to ports on different switches (e.g., in an active/passive configuration). This is partially addressed on 4.1.2 (new section in -06), but only in terms of moving validation state when something like LACP reconfigures. This has a couple of shortcomings: a) the alternative of statically allowing all source addresses through all teamed/aggregated links (decouples SAVI state from link teaming/aggregation state) should also be mentioned, and b) the new text implies that LACP is the only way to cause this situation - it's not, so LACP should be used as an example. VRRP is another example. (1) Some of the software switch implementations are single instance switches whose implementation is distributed across multiple physical servers. This results in concerns similar to the link aggregation discussion above. I don't think this has been addressed, but the notion of single-instance switches could be added to the generalization of the new text in 4.1.2. (2) Live migration of virtual machines among physical servers causes relocation of MAC addresses across switch ports. A so-called gratuitous ARP is often used to inform the network of the MAC address move; port-based source address validation information needs to move in response to such ARPs. (3) MAC address relocation is also used as a failure recovery technique; the surviving hardware element (e.g., host in a cluster) takes over the MAC addresses of the failed hardware; like the previous case, a gratuitous ARP is a common means of informing the network that the MAC address has moved, and source address validation information needs to move in response to it. Minor issues: There doesn't seem to be much discussion of dynamic network reconfiguration, which may change traffic egress points. VRRP may be a useful example to discuss beyond the typical routing protocol updates to forwarding tables. A paragraph has been added to 5.2.3 to address all three of the above concerns. I guess that's ok, but I would have liked to see some text pointing out that a MAC move can be detected by the switches and used to update SAVI state about which port(s) a MAC is accessed through. Thanks, --David -Original Message- From: Black, David Sent: Friday, May 13, 2011 1:03 AM To: McPherson, Danny; Fred Baker; joel.halp...@ericsson.com; gen- a...@ietf.org Cc: Black, David; Christian Vogt; Jean-Michel Combes; Jari Arkko; s...@ietf.org Subject: Gen-ART review of draft-ietf-savi-threat-scope-05 I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-savi-threat-scope-05 Reviewer: David L. Black Review Date: 12 May 2011 IETF LC End Date: 18 May 2011 Summary: This draft is on the right track, but has open issues, described in the review. This draft discusses the threats and deployment environment for IP source address validation with particular attention to finer-grain validation that could be used within a network to validate IP addresses closer to the sources of network traffic than ingress to an ISP's network. Major issues: There is no discussion of link teaming or aggregation (e.g., via LACP); this may affect source address validation functionality by requiring the same validation checks on all aggregated ports. An important case to discuss
Gen-ART review of draft-ietf-pwe3-mpls-eth-oam-iwk-07
The -07 version of this draft addresses all of the nits noted in the Gen-ART review of the -06 version. This draft is ready for publication as a Proposed Standard RFC. Thanks, --David From: Black, David Sent: Monday, August 20, 2012 9:58 PM To: dinmo...@hotmail.com; nabil.n.bi...@verizon.com; saja...@cisco.com; gen-...@ietf.org Cc: Black, David; p...@ietf.org; ietf@ietf.org Subject: Gen-ART review of draft-ietf-pwe3-mpls-eth-oam-iwk-06 I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-pwe3-mpls-eth-oam-iwk-06 Reviewer: David L. Black Review Date: August 20, 2012 IETF LC End Date: August 20, 2012 Summary: This draft is basically ready for publication, but has nits that should be fixed before publication. This draft covers defect behavior for Ethernet pseudowires, including defect state mapping and PE defect reporting behavior. The draft is generally in good shape. I found a few minor nits. 1) The draft uses a lot of acronyms - while each acronym appears to be expanded on first use, an additional section near the start of the draft listing all of them would be helpful. 2) There's a typo in the first paragraph of section 2: covers the following Ethernet OAM (Opertaions, Administration and Opertaions - Operations. 3) The following normative reference is incomplete - please add additional information that will enable a reader to locate the referenced document: [MEF16] Ethernet Local Management Interface, MEF16, January 2006. 4) idnits 2.12.13 did not like the pagination: == The page length should not exceed 58 lines per page, but there was 22 longer pages, the longest (page 1) being 61 lines Thanks, --David David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 david.bl...@emc.commailto:david.bl...@emc.comMobile: +1 (978) 394-7754
Gen-ART review of draft-ietf-softwire-dslite-deployment-07
Authors, The -07 version of this draft has resolved most of the concerns raised by the Gen-ART review of the -06 version of this draft, with one significant exception: [5] Section 2.8 discusses IPv4 accounting at the AFTR, but notes that the AFTR does not have detailed customer identity information. Does that create a theft of service possibility? If so, that possibility should be mentioned as a security consideration. Also, Section 2.8 ought to be expanded with a sentence or two explaining why the AFTR does not have that identity information, and in particular to explain whether and why it is unreasonable in some or all cases to expect that customer identity information be provided to the AFTR as part of provisioning each customer's softwire. This has been partially resolved - the explanation of why the AFTR may not have that identity information has been added. Here's the text from the -07 draft. Alternatively, AFTR may perform accounting for IPv4 traffic. However, operators must be aware that this will introduce some challenges especially in DSL deployment. In DSL deployment, the AAA transaction normally happens between the edge router (i.e., Broadband Network Gateway) and AAA server. [RFC6333] does not require the AFTR to interact with the AAA server or edge router. Thus, AFTR may not have the AAA parameters (e.g., Account Session ID) associated to users to generate IPv4 accounting record. The accounting process at the AFTR is only necessary if the operator requires separating per user accounting records for IPv4 and IPv6 traffic. If the per user IPv6 accounting records, collected by the edge router, are sufficient, and the additional complexity of enabling IPv4 accounting at the ATFR is not required. It is important to notice that, since the IPv4 traffic is encapsulated in IPv6 packets, the data collected by the edge router for IPv6 traffic already contain the total amount of traffic (i.e. IPv4 and IPv6). This revised text removes my concern about a security risk, but I think the result still provides more support than it should for trying to do accounting without all the information needed to do it. Please insert a sentence before The accounting process at the AFTR is only necessary if ... to state that IPv4 traffic accounting at the AFTR is not recommended when the necessary AAA parameters are not available. The following sentence would suffice. IPv4 traffic accounting at the AFTR is not recommended when the AAA parameters necessary to generate complete IPv4 accounting records are not available. Also, the response to this nit could be improved: Section 3.2.2 uses 192.0.0.2/32 as an example IP address for the B4. That section should also cross-reference Section 5.7 on RFC 6333 on IP address assignment to B4s, as other IP addresses may be used. My original comment wasn't complete - here's a suggested text change that should be clearer: OLD Operators should assign the same IPv4 address (i.e., 192.0.0.2/32) to all AFTRs. IANA allocates 192.0.0.0/29 [RFC6333] Section 5.7 that can be used for this purpose. NEW Operators should assign the same IPv4 address (e.g., 192.0.0.2/32 [RFC6333]) to all AFTRs. IANA has allocated the 192.0.0.0/29 network prefix to provide IPv4 addresses for this purpose [RFC 6333]. END Thanks, --David -Original Message- From: Black, David Sent: Monday, October 15, 2012 7:10 PM To: yiu_...@cable.comcast.com; roberta.magli...@telecomitalia.it; carlw@mcsr- labs.org; christian.jacque...@orange.com; mohamed.boucad...@orange.com; gen- a...@ietf.org Cc: softwi...@ietf.org; Black, David; ietf@ietf.org; Ralph Droms Subject: Gen-ART review of draft-ietf-softwire-dslite-deployment-06 I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-softwire-dslite-deployment-06 Reviewer: David L. Black Review Date: October 15, 2012 IETF LC End Date: October 16, 2012 IESG Telechat Date: October 25, 2012 Summary: This draft is on the right track but has open issues, described in the review. This is a generally well-written draft that expands considerably on the brief deployment considerations for DS-Lite in Appendix A of RFC 6333. The draft is clear and reasonably well-written, and a significant improvement on that RFC 6333 Appendix, although an understanding of RFC 6333 is necessary to understand this draft, which seems completely reasonable. The B4 and AFTR acronyms are clever - kudos to whomever came up with those. I found five open issues, all of which are minor. Minor Issues: [1] Ironically, the first issue is that something should be said about the relationship of this draft to Appendix A of RFC 6333. It probably
RE: Gen-ART review of draft-ietf-softwire-dslite-deployment-06
Yiu, Thank you for your responses - most of them look fine, and in particular anything that I don't comment on here is acceptable to me. [YL] In 2.2, we will add: Note that reassembly at Tunnel Exit-Point is resource intensive. A large number of B4 may terminate on the same AFTR. If many B4 fragment the packets, it would increase sufficient load to the AFTR for reassembly. We recommend the operator should increase the MTU size of the IPv6 network between B4 and AFTR to avoid fragmentation. I would change is to may be in the first line. [5] Section 2.8 discusses IPv4 accounting at the AFTR, but notes that the AFTR does not have detailed customer identity information. Does that create a theft of service possibility? If so, that possibility should be mentioned as a security consideration. Also, Section 2.8 ought to be expanded with a sentence or two explaining why the AFTR does not have that identity information, and in particular to explain whether and why it is unreasonable in some or all cases to expect that customer identity information be provided to the AFTR as part of provisioning each customer's softwire. [YL] Good catch. Actually I believe AFTR does have both IPv4 and IPv6 to identify the customer. I suggest we remove but it will potentially introduce some additional complexity because the AFTR does not have detailed customer identity information. That's definitely an easy way to address that issue, and it's fine with me. Section 2.3 on MTU Considerations could usefully mention MTU discovery techniques, as possibilities for customer IPv4 traffic to adapt to a smaller IPv4 MTU. If this is done, it would be useful to mention RFC 4821 in addition to the mention of RFC 1191 in RFC 6333. [YL] We would consider RFC 4821. However, the challenge is I don't have information how many current OS support RFC 4821. Since DS-lite is a transition technology, it would be unreasonable to ask the OS company to implement RFC 4821 for DS-lite. That's ok - this was a nit. - Are one or both types of logging recommended? [YL] We tempted to recommend source-specific log. However, some regulators require to use both and the regulations vary country from country, this is why we left it open and let the operators to decide. Please add a version of your explanation to the draft. In Section 2.7, I'm having a hard time understanding which traffic is intended to be subject to the Outgoing Policies and the Incoming Policies. Expanding each of those two bullets to explain what traffic is subject to each class of policies would help. [YL] Does this help? Outgoing Policies apply to packets originating from B4 to IPv4 network. Incoming Policies apply to packets originating from IPv4 network to B4. Yes, that's clearer, although the B4 is not the network endpoint for any of that traffic. I suggest: Outgoing Policies apply to packets originating from behind the B4 with a destination on the IPv4 network. Incoming Policies apply to packets originating from the IPv4 network to a destination behind the B4. Thanks, --David -Original Message- From: Lee, Yiu [mailto:yiu_...@cable.comcast.com] Sent: Wednesday, October 17, 2012 8:46 PM To: Black, David; roberta.magli...@telecomitalia.it; ca...@mcsr-labs.org; christian.jacque...@orange.com; mohamed.boucad...@orange.com; gen-...@ietf.org Cc: softwi...@ietf.org; ietf@ietf.org; Ralph Droms Subject: Re: Gen-ART review of draft-ietf-softwire-dslite-deployment-06 Hi David, Thanks very much for review the draft. Comments inline. Thanks, Yiu On 10/15/12 7:10 PM, Black, David david.bl...@emc.com wrote: I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-softwire-dslite-deployment-06 Reviewer: David L. Black Review Date: October 15, 2012 IETF LC End Date: October 16, 2012 IESG Telechat Date: October 25, 2012 Summary: This draft is on the right track but has open issues, described in the review. This is a generally well-written draft that expands considerably on the brief deployment considerations for DS-Lite in Appendix A of RFC 6333. The draft is clear and reasonably well-written, and a significant improvement on that RFC 6333 Appendix, although an understanding of RFC 6333 is necessary to understand this draft, which seems completely reasonable. The B4 and AFTR acronyms are clever - kudos to whomever came up with those. I found five open issues, all of which are minor. Minor Issues: [1] Ironically, the first issue is that something should be said about the relationship of this draft to Appendix A of RFC 6333. It probably suffices to say that this draft expands on the material in that Appendix, as I see no need
Gen-ART review of draft-ietf-softwire-dslite-deployment-06
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-softwire-dslite-deployment-06 Reviewer: David L. Black Review Date: October 15, 2012 IETF LC End Date: October 16, 2012 IESG Telechat Date: October 25, 2012 Summary: This draft is on the right track but has open issues, described in the review. This is a generally well-written draft that expands considerably on the brief deployment considerations for DS-Lite in Appendix A of RFC 6333. The draft is clear and reasonably well-written, and a significant improvement on that RFC 6333 Appendix, although an understanding of RFC 6333 is necessary to understand this draft, which seems completely reasonable. The B4 and AFTR acronyms are clever - kudos to whomever came up with those. I found five open issues, all of which are minor. Minor Issues: [1] Ironically, the first issue is that something should be said about the relationship of this draft to Appendix A of RFC 6333. It probably suffices to say that this draft expands on the material in that Appendix, as I see no need to specify that this draft updates RFC 6333 solely to change non-normative material in an Appendix. [2] The MTU increase technique in Section 2.2 is a may, which is consistent with Section 5.3 of RFC 6333. OTOH, Section 2.2 of this draft should also discuss the AFTR resource exhaustion concern that described in Section 6.3 of RFC 6333, as that is a potential operational reason for an ISP to increase MTU size (e.g., if customer sourcing of large IPv4 packets is not sufficiently rare). [3] Section 2.7 refers to the AFTR's internal interface. There may be two internal interfaces, the physical IPv6 interface (outer header) and the tunnel's IPv4 interface (inner header). The text should be clarified to indicate which interface is involved - it appears that the AFTR's physical IPv6 interface is intended in this section. [4] Section 2.7 cites RFC 6333 for use of DHCPv6 with DS-Lite. RFC 6334 should be cited - either in addition to or instead of RFC 6333. [5] Section 2.8 discusses IPv4 accounting at the AFTR, but notes that the AFTR does not have detailed customer identity information. Does that create a theft of service possibility? If so, that possibility should be mentioned as a security consideration. Also, Section 2.8 ought to be expanded with a sentence or two explaining why the AFTR does not have that identity information, and in particular to explain whether and why it is unreasonable in some or all cases to expect that customer identity information be provided to the AFTR as part of provisioning each customer's softwire. Nits: Section 2.3 on MTU Considerations could usefully mention MTU discovery techniques, as possibilities for customer IPv4 traffic to adapt to a smaller IPv4 MTU. If this is done, it would be useful to mention RFC 4821 in addition to the mention of RFC 1191 in RFC 6333. Section 2.4 should define lawful intercept. It would be helpful to cite a reference for this concept if something appropriate can be found. Section 2.5: - Are one or both types of logging recommended? - Last paragraph on p.4, timestamped log is not a good verb phrase. maintain a timestamped log of would be a better replacement. - Last paragraph in section, where is the batch file sent? In Section 2.7, I'm having a hard time understanding which traffic is intended to be subject to the Outgoing Policies and the Incoming Policies. Expanding each of those two bullets to explain what traffic is subject to each class of policies would help. Section 3.2.2.2 uses 192.0.0.2/32 as an example IP address for the B4. That section should also cross-reference Section 5.7 on RFC 6333 on IP address assignment to B4s, as other IP addresses may be used. idnits 2.12.13 found a tiny nit - draft-ietf-pcp-base is now at version 28. Thanks, --David David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 david.bl...@emc.com Mobile: +1 (978) 394-7754
RE: Last Call: draft-ietf-storm-iser-12.txt (iSCSI Extensions for RDMA Specification) to Proposed Standard
For those interested in what has changed in this draft by comparison to the specification of iSER in RFC 5046, here's a reasonably readable diff that shows the text changes: http://www.stiemerling.org/ietf/storm-review/diff-rfc5046-to-iser.html and the edited version of RFC 5046 on which this was based http://www.stiemerling.org/ietf/storm-review/rfc5046-edited.txt All of the content of RFC 5046 is preserved in that version, but the changes to improve the diff include swapping the order of sections 1 and 2 in order to match the storm-iser draft, and taking out page gutters that confuse the IETF diff tool. And many thanks to our AD (Martin Stiemerling) for hosting this on his web site. FYI, --David -Original Message- From: ietf-announce-boun...@ietf.org [mailto:ietf-announce-boun...@ietf.org] On Behalf Of The IESG Sent: Monday, October 08, 2012 10:13 AM To: IETF-Announce Cc: st...@ietf.org Subject: Last Call: draft-ietf-storm-iser-12.txt (iSCSI Extensions for RDMA Specification) to Proposed Standard The IESG has received a request from the STORage Maintenance WG (storm) to consider the following document: - 'iSCSI Extensions for RDMA Specification' draft-ietf-storm-iser-12.txt as 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-10-22. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract iSCSI Extensions for RDMA provides the RDMA data transfer capability to iSCSI by layering iSCSI on top of an RDMA-Capable Protocol. An RDMA-Capable Protocol provides RDMA Read and Write services, which enable data to be transferred directly into SCSI I/O Buffers without intermediate data copies. This document describes the extensions to the iSCSI protocol to support RDMA services as provided by an RDMA- Capable Protocol. This document obsoletes RFC 5046. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-storm-iser/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-storm-iser/ballot/ No IPR declarations have been submitted directly on this I-D.
RE: Gen-ART review of draft-ietf-dime-rfc4005bis-11
Barry, 5) Statement that the string contains an FQDN, as stated for one case of the Tunnel-Client-Endpoint AVP in 4.5.4. That specific statement is incomplete, as it needs to be accompanied by a normative reference to a document that specifies the format of internationalized domain names, and probably needs to also state which types of labels (e.g., A-label, U-label) are allowed. Every use of UTF8String in this draft needs to be checked, and most of them are likely to need some attention. The ongoing work in the precis WG may help with some of this, and I would suggest talking to the APP ADs, especially Pete Resnick (hi Pete) before embarking on significant work in this area in order to avoid wasted or duplicated efforts. OK, this last one bothers me a lot: you /seem /to be suggesting that we hold up this draft to wait for the result of a WG which has yet to publish a problem statement. I'm sure that that is not the case, but it sure sounds like it. David can clarify if I'm wrong, but that's not what it sounds like to me. What it sounds like he's suggesting is that you talk with the precis people to see if things are OK, or if there's anything you should be doing differently. I'm adding the precis chairs to this message, and asking them to respond to this point. It's somewhere in between, as things are definitely *not* OK at the moment, but my reason for suggesting a discussion with the précis folks is to take advantage of their insights and work to date. If I thought this draft needed to wait for the output of the précis WG, I would have indicated which précis draft ought to be a normative reference (and I did not do that). Whether that's a good idea will only be clear after every use of UTF8String is checked. FWIW, the FQDN situation is worked out, start with a normative reference to RFC 5890, which includes the specification of the various label types. A tangential point, while I'm here: [4] Based on this text in 4.4.9: The use of this AVP is NOT RECOMMENDED; the AVPs defined by Korhonen, et al. [RFC5777] SHOULD be used instead. I would have expected RFC5777 to be a Normative Reference, not an Informative Reference. I don't care particularly, but I don't think that it's really necessary to understand RFC 5777 to understand this document. It would seem odd, in general, if something that's a MUST implement or SHOULD implement weren't a normative reference. But I haven't (yet) looked at this particular case to see. My expectation is the same - if [RFC] is specified as MUST implement or SHOULD implement, then I usually expect that RFC to be a normative reference. Thanks, --David David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 david.bl...@emc.com Mobile: +1 (978) 394-7754
RE: Gen-ART review of draft-ietf-dime-rfc4005bis-11
Glen, Picking up the topics that weren't in Barry's email ... 1) String preparation so that tests for equality work as expected. This may suffice for the Called-Station-ID AVP (4.2.5) and Calling-Station-ID AVP (4.2.6) if the internal structure of those strings is not used in authorization. Both those AVPs are specified to contain ASCII encoded as UTF-8. Is string preparation necessary in that case? Not in the full glory that is needed for serious usage of UTF-8, but it looks like the language in the draft should be tightened. At a minimum, a MUST is in order to require use of 7-bit ASCII encoded as UTF-8. Among the reasons for such a requirement is to prohibit the various ISO/IEC 8859-* character sets (a/k/a Latin-*), which are 8-bit ASCII and not distinguishable from each other on the wire without an additional character set tag of some form. I would also suggest forbidding control characters (e.g., require displayable 7-bit ASCII characters) and saying something about case handling, starting with whether the strings are case sensitive or case insensitive. Case sensitivity is simpler to specify, but may not yield intuitive and/or expected results. If the strings are case insensitive, text should be added to say whether the strings are case-normalized on the wire and/or whether the recipient is expected to implement case- insensitive string comparison. 2) Detailed string format for a string that is processed by a protocol participant, e.g., the Callback-ID AVP (4.4.3). That format is unknown in this case. Please explain how that's supposed to result in interoperable processing by the protocol participant. [1] End of Section 2 on p.8: As a result, service cannot be started as a result of a response to an authorization-only request without introducing a significant security vulnerability. Please explain what to do about this - a simple rewrite with a SHOULD NOT would suffice, e.g.: As a result, service SHOULD NOT be started as a result of a response to an authorization-only request because that may introduce a significant security vulnerability. The text in question is descriptive, not prescriptive. That said, however, I think that it's not really clear. I think that it should say something like As a result, a new session cannot be started as a result of a response to an authorization-only request without introducing a significant security vulnerability. This should also be noted in the Security Considerations section. The rewrite helps, and make sure to add text about this in the Security Considerations section. == Missing Reference: 'BASE' is mentioned on line 219, but not defined That's definitely a problem. Was [I-D.ietf-dime-rfc3588bis] intended? No. The passage in question is a verbatim quote from RFC 4005. Ok, just fix this so idnits can find something else to complain about :-). Thanks, --David -Original Message- From: Glen Zorn [mailto:glenz...@gmail.com] Sent: Sunday, October 07, 2012 3:28 AM To: Black, David Cc: glenz...@gmail.com; lionel.mor...@orange.com; gen-...@ietf.org; dime- cha...@tools.ietf.org; draft-ietf-dime-rfc4005...@tools.ietf.org; ietf@ietf.org; d...@ietf.org; Benoit Claise Subject: Re: Gen-ART review of draft-ietf-dime-rfc4005bis-11 On 09/18/2012 06:53 AM, Black, David wrote: I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-dime-rfc4005bis-11 Reviewer: David L. Black Review Date: September 17, 2012 IETF LC End Date: September 18, 2012 IESG Telechat date: (if known) Summary: This draft is on the right track but has open issues, described in the review. This draft is part of a set of drafts that updates the DIAMETER protocol; this draft specifies the application of DIAMETER to AAA for network access. The draft is heavily based on RFC 4005, which it obsoletes, and requires significant DIAMETER familiarity (including familiarity with its companion drafts, starting with the rfc3588bis draft) for complete understanding. The draft is in good shape and reads well. I found one major open issue, a few minor issues, and several nits. Major issues: This draft makes significant use of UTF-8 in its formats (some subsections of sections 4.2, 4.4 and 4.5) for strings that are intended to be compared for equality or processed by protocol participants, but does not contain considerations for Unicode processing that are sufficient to support this usage. Examples of UTF-8 usage in this draft include: - 4.2.5 and 4.2.6: The NAS server may perform authorization based on the Called-Station-Id and Calling-Station-Id AVPs under some circumstances
Gen-ART review of draft-ietf-dime-rfc4005bis-11
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-dime-rfc4005bis-11 Reviewer: David L. Black Review Date: September 17, 2012 IETF LC End Date: September 18, 2012 IESG Telechat date: (if known) Summary: This draft is on the right track but has open issues, described in the review. This draft is part of a set of drafts that updates the DIAMETER protocol; this draft specifies the application of DIAMETER to AAA for network access. The draft is heavily based on RFC 4005, which it obsoletes, and requires significant DIAMETER familiarity (including familiarity with its companion drafts, starting with the rfc3588bis draft) for complete understanding. The draft is in good shape and reads well. I found one major open issue, a few minor issues, and several nits. Major issues: This draft makes significant use of UTF-8 in its formats (some subsections of sections 4.2, 4.4 and 4.5) for strings that are intended to be compared for equality or processed by protocol participants, but does not contain considerations for Unicode processing that are sufficient to support this usage. Examples of UTF-8 usage in this draft include: - 4.2.5 and 4.2.6: The NAS server may perform authorization based on the Called-Station-Id and Calling-Station-Id AVPs under some circumstances. - 4.4.3: The Callback-Id AVP is intended to be interpreted by the NAS. All use of UTF-8 in this draft relies upon the specification of the UTF8String format in the rfc3588bis draft. That specification is insufficient to support the usage in the above examples, and there are no Unicode considerations in this draft. Even binary comparison of Unicode strings for equality generally requires specification of string preparation (e.g., normalization) in order for string comparison to work as expected. The variety of Unicode strings in this draft makes it important to lay out the Unicode requirements and considerations for each AVP. I see at least 5 classes of possible Unicode requirements/considerations: 1) String preparation so that tests for equality work as expected. This may suffice for the Called-Station-ID AVP (4.2.5) and Calling-Station-ID AVP (4.2.6) if the internal structure of those strings is not used in authorization. 2) Detailed string format for a string that is processed by a protocol participant, e.g., the Callback-ID AVP (4.4.3). 3) Restriction of the string to ASCII-only, e.g., as already stated for the Framed-Route AVP (4.4.10.5.3). 4) Specification that the string is for display to human users only, e.g., as already stated for the Reply-Message AVP (4.2.9). 5) Statement that the string contains an FQDN, as stated for one case of the Tunnel-Client-Endpoint AVP in 4.5.4. That specific statement is incomplete, as it needs to be accompanied by a normative reference to a document that specifies the format of internationalized domain names, and probably needs to also state which types of labels (e.g., A-label, U-label) are allowed. Every use of UTF8String in this draft needs to be checked, and most of them are likely to need some attention. The ongoing work in the precis WG may help with some of this, and I would suggest talking to the APP ADs, especially Pete Resnick (hi Pete) before embarking on significant work in this area in order to avoid wasted or duplicated efforts. Minor Issues: [1] End of Section 2 on p.8: As a result, service cannot be started as a result of a response to an authorization-only request without introducing a significant security vulnerability. Please explain what to do about this - a simple rewrite with a SHOULD NOT would suffice, e.g.: As a result, service SHOULD NOT be started as a result of a response to an authorization-only request because that may introduce a significant security vulnerability. This should also be noted in the Security Considerations section. [2] In the message formats in Section 3, QoS-Filter-Rule is inconsistently capitalized. Also the use of QoSFilterRule as the format for the QoS-Filter-Rule AVP in Section 4.1.1 is potentially confusing. Please add a sentence in 4.1.1 to say that QoSFilterRule is the format for the QoS-Filter-Rule AVP. [3] Section 4.2.1. In this and the other AVP Flag Rules tables, please explain what the values in the MUST and MUST NOT columns mean. [4] Based on this text in 4.4.9: The use of this AVP is NOT RECOMMENDED; the AVPs defined by Korhonen, et al. [RFC5777] SHOULD be used instead. I would have expected RFC5777 to be a Normative Reference, not an Informative Reference. Nits/editorial comments: After the command table in Section 3 and other similar tables, please add a sentence to say that the
RE: Proposed IETF Meeting Calendar 2018 - 2022
The first week of November dates for 2018, 2021 and 2022 are likely to conflict with T10 (SCSI storage standards body). Thanks, --David (storm WG co-chair) -Original Message- From: wgchairs-boun...@ietf.org [mailto:wgchairs-boun...@ietf.org] On Behalf Of IETF Administrative Director Sent: Thursday, September 06, 2012 3:16 PM To: IETF Announcement List Cc: i...@ietf.org; i...@iab.org; ietf@ietf.org; wgcha...@ietf.org Subject: Proposed IETF Meeting Calendar 2018 - 2022 All; Below are suggested Meeting dates for 2018 - 2022, IETF's 101 - 115. The IAOC is soliciting the community's feedback before adopting. Comments appreciated to ietf@ietf.org by 20 September 2012. Ray 2018 IETF 101 18-23 March 2018 IETF 102 22-27 July 2018 IETF 103 4 - 9 November 2018 2019 IETF 104 24 - 29 March 2019 IETF 105 21 - 26 July 2019 IETF 106 17 - 22 November 2019 2020 IETF 107 22 - 27 March 2020 IETF 108 26 - 31 July 2020 IETF 109 15 - 20 November 2020 2021 IETF 110 21 - 26 March 2021 IETF 111 25 - 30 July 2021 IETF 112 7 - 12 November 2021 2022 IETF 113 20 - 25 March 2022 IETF 114 24 - 29 July 2022 IETF 115 6 - 11 November 2022
Gen-ART review of draft-ietf-pwe3-mpls-eth-oam-iwk-06
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-pwe3-mpls-eth-oam-iwk-06 Reviewer: David L. Black Review Date: August 20, 2012 IETF LC End Date: August 20, 2012 Summary: This draft is basically ready for publication, but has nits that should be fixed before publication. This draft covers defect behavior for Ethernet pseudowires, including defect state mapping and PE defect reporting behavior. The draft is generally in good shape. I found a few minor nits. 1) The draft uses a lot of acronyms - while each acronym appears to be expanded on first use, an additional section near the start of the draft listing all of them would be helpful. 2) There's a typo in the first paragraph of section 2: covers the following Ethernet OAM (Opertaions, Administration and Opertaions - Operations. 3) The following normative reference is incomplete - please add additional information that will enable a reader to locate the referenced document: [MEF16] Ethernet Local Management Interface, MEF16, January 2006. 4) idnits 2.12.13 did not like the pagination: == The page length should not exceed 58 lines per page, but there was 22 longer pages, the longest (page 1) being 61 lines Thanks, --David David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 david.bl...@emc.commailto:david.bl...@emc.comMobile: +1 (978) 394-7754
RE: Gen-ART review of draft-vegoda-cotton-rfc5735bis-03
The -03 version of this draft addresses the nits in the Gen-ART version of the -02 version. Section 5 has been removed in the -03 version, so the nit that was there is gone. Thanks, --David -Original Message- From: Black, David Sent: Thursday, August 09, 2012 7:05 PM To: michelle.cot...@icann.org; leo.veg...@icann.org; gen-...@ietf.org Cc: Black, David; ietf@ietf.org Subject: Gen-ART review of draft-vegoda-cotton-rfc5735bis-02 I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-vegoda-cotton-rfc5735bis-02 Reviewer: David L. Black Review Date: August 9, 2012 IETF LC End Date: August 9, 2012 Summary: This draft is basically ready for publication, but has nits that should be fixed before publication. This draft provides an updated list of the special use IPv4 address blocks that have been allocated by IANA along with explanations of their special uses. I found one nit and idnits found another one. Section 5 - the first sentence in the second paragraph is: The domain name and IP address spaces involve policy issues (in addition to technical issues) so that the requirements of [RFC2860] do not apply generally to those spaces. I'm surprised by do not apply generally. I would have expected that the policy issues create requirements and constraints above and beyond the requirements in RFC 2860 as opposed to replacing those requirements. idnits 2.12.13 complained about a lot of IP addresses that aren't in the address ranges used for examples. These complaints can be ignored, but idnits did find one actual nit: == Unused Reference: 'RFC6441' is defined on line 346, but no explicit reference was found in the text Thanks, --David David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 david.bl...@emc.com Mobile: +1 (978) 394-7754
Gen-ART review of draft-vegoda-cotton-rfc5735bis-02
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-vegoda-cotton-rfc5735bis-02 Reviewer: David L. Black Review Date: August 9, 2012 IETF LC End Date: August 9, 2012 Summary: This draft is basically ready for publication, but has nits that should be fixed before publication. This draft provides an updated list of the special use IPv4 address blocks that have been allocated by IANA along with explanations of their special uses. I found one nit and idnits found another one. Section 5 - the first sentence in the second paragraph is: The domain name and IP address spaces involve policy issues (in addition to technical issues) so that the requirements of [RFC2860] do not apply generally to those spaces. I'm surprised by do not apply generally. I would have expected that the policy issues create requirements and constraints above and beyond the requirements in RFC 2860 as opposed to replacing those requirements. idnits 2.12.13 complained about a lot of IP addresses that aren't in the address ranges used for examples. These complaints can be ignored, but idnits did find one actual nit: == Unused Reference: 'RFC6441' is defined on line 346, but no explicit reference was found in the text Thanks, --David David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 david.bl...@emc.com Mobile: +1 (978) 394-7754
Gen-ART review of draft-ietf-bliss-shared-appearances-13
These resolutions have been carried forward to the -13 version of the draft. Thanks, --David -Original Message- From: Black, David Sent: Friday, July 13, 2012 6:25 PM To: Black, David; alan.b.johns...@gmail.com; mohsen.soro...@sylantro.com; vvenka...@gmail.com; gen-...@ietf.org Cc: Shida Schubert; bl...@ietf.org; IETF Discussion; Robert Sparks Subject: Gen-ART review of draft-ietf-bliss-shared-appearances-12 The -12 version of this draft resolves all of the comments in the Gen-ART review of the -11 version. Thanks, --David -Original Message- From: Black, David Sent: Thursday, June 28, 2012 4:51 PM To: alan.b.johns...@gmail.com; mohsen.soro...@sylantro.com; vvenka...@gmail.com; gen-...@ietf.org Cc: Black, David; Shida Schubert; bl...@ietf.org; IETF Discussion; Robert Sparks Subject: Gen-ART review of draft-ietf-bliss-shared-appearances-11 I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-bliss-shared-appearances-11 Reviewer: David L. Black Review Date: June 28, 2012 IETF LC End Date: June 28, 2012 IESG Telechat date: (if known) Summary: This draft is on the right track but has open issues, described in the review. This draft describes support for shared appearances in support of multi-line and shared-line telephone often found in businesses. All of the open issues are minor. The draft is well-written and reasonably clear for the most part, although significant SIP expertise is required to completely understand it. Major issues: None. Minor issues: 4.1 - REQ-16: in this case, seizing the line is the same thing as dialing. That seems wrong - I would have thought it was a prerequisite as opposed to the same thing because seizing the line is immediately followed by a dialing request. 5.3. A user may select an appearance number but then abandon placing a call (go back on hook). In this case, the UA MUST free up the appearance number by removing the event state with a PUBLISH as described in [RFC3903]. What happens when that can't be done due to UA or network failure? 5.4. A 400 response is returned if the chosen appearance number is invalid, Is that always a 400 (Bad Request) or is any 4xx response allowed? If it's always 400, add the words Bad Request after 400. If the Appearance Agent policy does not allow this, a 400 response is returned. Same question. In addition, is 403 Forbidden allowed here? If an INVITE is sent by a member of the group to the shared AOR (i.e. they call their own AOR), the Appearance Agent MUST assign two appearance numbers. The first appearance number will be the one selected or assigned to the outgoing INVITE. The second appearance number will be another one assigned by the Appearance Agent for the INVITE as it is forked back to the members of the group. How does that interact with the single appearance UAs in 8.1.1 that won't understand the second appearance number? A warning that such a UA can't pick up its call to its own AOR would suffice, either here or in 8.1.1. 9.1 A UA that has no knowledge of appearances must will only have appearance numbers for outgoing calls if assigned by the Appearance Agent. If the non-shared appearance UA does not support Join or Replaces, all dialogs could be marked exclusive to indicate that these options are not available. Should that could be marked be changed to SHOULD be marked ? Also, analogous questions for could in 9.2 and can in 9.3. All three of these affect interoperability. 12. Security Considerations In general, this section is weak on rationale - the second, third and fourth paragraphs should all explain more about the purpose of and/or rationale for their security requirements (e.g., what does the security mechanism protect against and when/why might that protection be desired and/or required?). NOTIFY or PUBLISH message bodies that provide the dialog state information and the dialog identifiers MAY be encrypted end-to-end using the standard mechanisms. What are the standard mechanisms? List them, and provide references, please. Please ensure that the section 6 XML and Section 7 ABNF are syntax-checked with actual tools. Nits/editorial comments: p.10: The next section discusses the operations used to implement parts of the shared appearance feature. The following list describes the operations ... would be better. 5.3.1. A UA wanting to place a call but not have an appearance number assigned publishes before sending the INVITE without an 'appearance' element
Gen-ART review of draft-polk-local-emergency-rph-namespace-02
The nits in the Gen-ART review of the -01 version of this draft have not been addressed in the -02 version. idnits found one existing nit and one new one: == It seems as if not all pages are separated by form feeds - found 0 form feeds but 8 pages == Line 156 has weird spacing: '...n, this is a ...' Thanks, --David -Original Message- From: Black, David Sent: Tuesday, July 12, 2011 8:45 PM To: James M. Polk; gen-...@ietf.org; ietf@ietf.org Cc: Black, David; Robert Sparks Subject: Gen-ART review of draft-polk-local-emergency-rph-namespace-01 I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-polk-local-emergency-rph-namespace-01 Reviewer: David L. Black Review Date: July 12, 2011 IETF LC End Date: July 13, 2011 Summary: This draft is basically ready for publication, but has nits that should be fixed before publication. This draft defines a SIP Resource Priority header namespace, esnet, for use in providing preferential treatment to emergency calls (e.g., from on-scene responders). This field is an addition to rather than a replacement for existing notions of priority in the SIP Resource Priority header. Section 2 explains why this was done, but section 2 is a bit sloppy and imprecise. Some level of imprecision is necessary as this draft deliberately does not specify how this header namespace is used to provide preferential treatment. Nonetheless, the following two items could be improved in Section 2's discussion: 1) Explain the reason for including the second paragraph, the paragraph that references RFC 4412's discouragement of modification of priorities within an administrative domain. That paragraph's not connected to the rest of section 2. 2) Explicitly state that one of the anticipated uses of the priorities in the esnet namespace is to override the ordinary priorities found elsewhere in the Resource Priority header. Small nit: There's an extraneous to in the first line of section 3: The esnet namespace should not to be considered generic for all ^^ idnits 2.12.12 found a few formatting problems: == You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See http://trustee.ietf.org/license-info/) == It seems as if not all pages are separated by form feeds - found 0 form feeds but 7 pages == The copyright year in the IETF Trust and authors Copyright Line does not match the current year Thanks, --David David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 david.bl...@emc.com Mobile: +1 (978) 394-7754
