Gen-ART review of draft-ietf-pwe3-mpls-eth-oam-iwk-07

[Black, David]

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.com<mailto:david.bl...@emc.com>Mobile: +1 (978) 394-7754

Gen-ART review of draft-ietf-pkix-rfc2560bis-15

[Black, David]

Authors,

I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, 
please
see the FAQ at .

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
"MAY"s 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.1

Gen-ART review of draft-ietf-savi-threat-scope-06

[Black, David]

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 

RE: Gen-ART review of draft-ietf-savi-threat-scope-06

[Black, David]

> 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
> >
&g

RE: Gen-ART review of draft-ietf-savi-threat-scope-06

[Black, David]

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

[Black, David]

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

RE: Gen-ART review of draft-ietf-pkix-rfc2560bis-15

[Black, David]

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

RE: Gen-ART review of draft-ietf-pkix-rfc2560bis-15

[Black, David]

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"  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.
> >>

RE: [savi] Gen-ART review of draft-ietf-savi-threat-scope-06

[Black, David]

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

[Black, David]

> 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"  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"  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 (importan

Gen-ART review of draft-ietf-pkix-rfc2560bis-16

[Black, David]

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
> "MAY"s 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

RE: [savi] Gen-ART review of draft-ietf-savi-threat-scope-06

[Black, David]

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

RE: Gen-ART review of draft-ietf-savi-threat-scope-07

[Black, David]

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&g

Gen-ART review of draft-ietf-karp-crypto-key-table-07

[Black, David]

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

[Black, David]

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; 
> 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  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 no

Gen-ART review of draft-eastlake-rfc5342bis-02

[Black, David]

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at

.

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-eastlake-rfc5342bis-03

[Black, David]

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

[Black, David]

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

Gen-ART review of draft-ietf-abfab-eapapplicability-03

[Black, David]

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at

.

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

[Black, David]

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

[Black, David]

> [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 
>  wrote:
> 
> >>>>>> "Black," == Black, David  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
&

RE: [abfab] Gen-ART review of draft-ietf-abfab-eapapplicability-03

[Black, David]

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

RE: [abfab] Gen-ART review of draft-ietf-abfab-eapapplicability-03

[Black, David]

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" 
mailto: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.com<http://cisco.com>]
Sent: Tuesday, June 18, 2013 1:47 PM
To: Black, David
Cc: stefan.win...@restena.lu<mailto:stefan.win...@restena.lu>; General Area 
Review Team; ab...@ietf.org<mailto:ab...@ietf.org>;
ietf@ietf.org<mailto: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 "applicatio

Gen-ART review of draft-ietf-abfab-eapapplicability-04

[Black, David]

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: Gen-ART review of draft-ietf-abfab-eapapplicability-05

[Black, David]

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 commen

Gen-ART review of draft-ietf-trill-directory-framework-05

[Black, David]

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 MAC&VLAN,
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

[Black, David]

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  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 MAC&VLAN,
> > 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
> > 

RE: Gen-ART review of draft-ietf-trill-directory-framework-06

[Black, David]

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 MAC&VLAN,
>   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 review of draft-eastlake-rfc5342bis-04

[Black, David]

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

[Black, David]

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: [karp] IANA policy for draft-ietf-karp-crypto-key-table-08

[Black, David]

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 t

RE: [karp] Gen-ART review of draft-ietf-karp-crypto-key-table-08

[Black, David]

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  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-ietf-dime-overload-reqs-10

[Black, David]

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at

.

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

[Black, David]

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

RE: Gen-ART review of draft-ietf-dime-overload-reqs-10

[Black, David]

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"  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
> &

Gen-ART review of draft-ietf-trill-directory-framework-07

[Black, David]

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 MAC&VLAN,
> > 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

Gen-ART review of draft-ietf-dime-overload-reqs-11

[Black, David]

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

Gen-ART review of draft-vegoda-cotton-rfc5735bis-02

[Black, David]

I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, 
please
see the FAQ at .

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

[Black, David]

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 purpo

Gen-ART review of draft-polk-local-emergency-rph-namespace-02

[Black, David]

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
> 

RE: Gen-ART review of draft-vegoda-cotton-rfc5735bis-03

[Black, David]

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-ietf-pwe3-mpls-eth-oam-iwk-06

[Black, David]

I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, 
please
see the FAQ at .

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.comMobile: +1 (978) 394-7754

RE: Proposed IETF Meeting Calendar 2018 - 2022

[Black, David]

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-dime-rfc4005bis-11

[Black, David]

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
.

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 th

RE: Gen-ART review of draft-ietf-dime-rfc4005bis-11

[Black, David]

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

[Black, David]

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
&g

Gen-ART review of draft-ietf-softwire-dslite-deployment-06

[Black, David]

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
.

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: (iSCSI Extensions for RDMA Specification) to Proposed Standard

[Black, David]

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:  (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'
>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-softwire-dslite-deployment-06

[Black, David]

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

Gen-ART review of draft-ietf-softwire-dslite-deployment-07

[Black, David]

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

Gen-ART review of draft-ietf-dime-overload-reqs-12

[Black, David]

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"  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.
> >

Gen-ART review of draft-ietf-sidr-bgpsec-threats-06

[Black, David]

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

[Black, 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.

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

RE: Transport Directorate review of: draft-ietf-l2vpn-vpls-mcast-14

[Black, 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.

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

RE: Transport Directorate review of: draft-ietf-l2vpn-vpls-mcast-14

[Black, David]

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 mu

RE: Gen-ART review of draft-ietf-sidr-bgpsec-threats-06

[Black, David]

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

RE: Gen-ART review of draft-ietf-sidr-bgpsec-threats-06

[Black, 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 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

[Black, David]

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

Gen-ART review of draft-ietf-sidr-bgpsec-threats-07

[Black, David]

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