Subject: [secdir] SECDIR review of draft-freytag-lager-variant-rules-03

From: Chris Lonvick <[email-masked]>
Date: Sun, 29 Jan 2017 20:46:23 -0600

Hi,

I have reviewed this document as part of the security directorate's 
ongoing effort to review all IETF documents being processed by the IESG. 
These comments were written primarily for the benefit of the security 
area directors. Document editors and WG chairs should treat these 
comments just like any other last call comments.

I consider this draft to be ready with issues.

The document is well written and thorough but has no content in the 
Security Considerations section. The guidance provided in this 
INFORMATIONAL document appears to be sound but it should still provide a 
statement of how this work attempts to address the security concerns of 
RFC 7948. For perspective, the title of section 12.1 of the Security 
Considerations section is "LGRs Are Only a Partial Remedy for Problem 
Space".

My recommendation is that a Security Considerations section for this 
document incorporate the Security Considerations section of RFC 7948, 
along with statements of how the document addresses the obtainable 
remediations, and what implementers should continue to be concerned about.

Thanks,
Chris

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Mon, 30 Jan 2017 18:48:17 +0000

Thanks for the review, Chris. I should note that my document shepherd review of the -02 version of this draft also produced feedback about the need to add Security Considerations text. The author added text and published the -03 version on 23 January. Chris, could you please look at -03 and see how well the text addresses your comments modulo what you’ve shared below? I assume that you meant RFC 7940 (Representing Label Generation Rulesets Using XML) when you wrote RFC 7948 (Internet Exchange BGP Route Server Operations).

Scott

From: Chris Lonvick [mailto:[email-masked]]
Sent: Sunday, January 29, 2017 9:46 PM
To: [email-masked]; [email-masked]; [email-masked]
Subject: [EXTERNAL] SECDIR review of draft-freytag-lager-variant-rules-03

Hi,

I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments.

The document is well written and thorough but has no content in the Security Considerations section. The guidance provided in this INFORMATIONAL document appears to be sound but it should still provide a statement of how this work attempts to address the security concerns of RFC 7948. For perspective, the title of section 12.1 of the Security Considerations section is "LGRs Are Only a Partial Remedy for Problem Space".

My recommendation is that a Security Considerations section for this document incorporate the Security Considerations section of RFC 7948, along with statements of how the document addresses the obtainable remediations, and what implementers should continue to be concerned about.

Thanks,
Chris

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Tue, 31 Jan 2017 13:37:46 +0000

Thanks, Chris. Asmus, do you have any issues with Chris’ suggestions?

Scott

From: Chris Lonvick [mailto:[email-masked]]
Sent: Tuesday, January 31, 2017 8:35 AM
To: Hollenbeck, Scott <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Subject: [EXTERNAL] Re: SECDIR review of draft-freytag-lager-variant-rules-03

Hi Scott,

Oops. :-) The assignment I got on the 19th was for -02 which was what I reviewed. I got a reminder on the 26th which was for -03 so I just put that in. And yes, I did mean 7940.

The Security Considerations section is much better in -03. However, if it is possible, I would still like to see something more in there. RFC 7940 has a short section in its Security Considerations section, noted below, about how LGRs are only a partial remedy to the problem. The new Security Considerations section in -03 seems to indicate that the problem space may be constrained by properly utilizing certain optional features of 7940. If that is correct, then perhaps the author would consider revising the last part of the second paragraph to more clearly state that?

Current:

   By including
   certain declarations that are optional under the schema and may not
   alter the results of processing a label, such an LGR supports the
   task of review and verification by more clearly expressing the
   intent.

Proposed:
   Utilizing certain optional declarations under the schema provides a clear expression
   of the label. When properly used, the label becomes unalterable and observably
   verifiable.

From there, I would also like to see a quick statement about any other areas that implementers should be aware of that are not addressed in this document. I'm not familiar enough with this technology to know if there is or isn't. If there are no other issues, or they are far outside the scope of this document, then don't worry about it.

Regards,
Chris

On 1/30/17 12:48 PM, Hollenbeck, Scott wrote:

   Scott

   From: Chris Lonvick [mailto:[email-masked]]
   Sent: Sunday, January 29, 2017 9:46 PM
   To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
   Subject: [EXTERNAL] SECDIR review of draft-freytag-lager-variant-rules-03

   Hi,

   Thanks,
   Chris

---

From: Chris Lonvick <[email-masked]>
Date: Tue, 31 Jan 2017 07:34:37 -0600

Hi Scott,

Oops. :-) The assignment I got on the 19th was for -02 which was what I 
reviewed. I got a reminder on the 26th which was for -03 so I just put 
that in. And yes, I did mean 7940.

The Security Considerations section is much better in -03. However, if 
it is possible, I would still like to see something more in there. RFC 
7940 has a short section in its Security Considerations section, noted 
below, about how LGRs are only a partial remedy to the problem. The new 
Security Considerations section in -03 seems to indicate that the 
problem space may be constrained by properly utilizing certain optional 
features of 7940. If that is correct, then perhaps the author would 
consider revising the last part of the second paragraph to more clearly 
state that?

Current:

    By including

Proposed:
    Utilizing certain optional declarations under the schema provides a 
clear expression
    of the label. When properly used, the label becomes unalterable and 
observably
    verifiable.

 From there, I would also like to see a quick statement about any other 
areas that implementers should be aware of that are not addressed in 
this document. I'm not familiar enough with this technology to know if 
there is or isn't. If there are no other issues, or they are far outside 
the scope of this document, then don't worry about it.

Regards,
Chris

On 1/30/17 12:48 PM, Hollenbeck, Scott wrote:
> Thanks for the review, Chris. I should note that my document shepherd 
> review of the -02 version of this draft also produced feedback about 
> the need to add Security Considerations text. The author added text 
> and published the -03 version on 23 January. Chris, could you please 
> look at -03 and see how well the text addresses your comments modulo 
> what you’ve shared below? I assume that you meant RFC 7940 
> (Representing Label Generation Rulesets Using XML) when you wrote RFC 
> 7948 (Internet Exchange BGP Route Server Operations).
>
> Scott
>
> *From:*Chris Lonvick [mailto:[email-masked]]
> *Sent:* Sunday, January 29, 2017 9:46 PM
> *To:* [email-masked]; [email-masked]; 
> [email-masked]
> *Subject:* [EXTERNAL] SECDIR review of 
> draft-freytag-lager-variant-rules-03
>
> Hi,
>
> ongoing effort to review all IETF documents being processed by the 
> IESG. These comments were written primarily for the benefit of the 
> security area directors. Document editors and WG chairs should treat 
> these comments just like any other last call comments.
>
> INFORMATIONAL document appears to be sound but it should still provide 
> a statement of how this work attempts to address the security concerns 
> of RFC 7948. For perspective, the title of section 12.1 of the 
> Security Considerations section is "LGRs Are Only a Partial Remedy for 
> Problem Space".
>

---

From: Asmus Freytag <[email-masked]>
Date: Tue, 31 Jan 2017 08:07:55 -0800

> Thanks, Chris. Asmus, do you have any issues with Chris’ suggestions?
See below.
> *Sent:* Tuesday, January 31, 2017 8:35 AM
> *To:* Hollenbeck, Scott <[email-masked]>; [email-masked]; 
> [email-masked]; [email-masked]
> *Subject:* [EXTERNAL] Re: SECDIR review of 
> Oops. :-) The assignment I got on the 19th was for -02 which was what 
> I reviewed. I got a reminder on the 26th which was for -03 so I just 
> put that in. And yes, I did mean 7940.
>
> The Security Considerations section is much better in -03.
>
Thanks.
>
> However, if it is possible, I would still like to see something more 
> in there. RFC 7940 has a short section in its Security Considerations 
> section, noted below, about how LGRs are only a partial remedy to the 
> problem.
>
That's a fundamental limitation.
>
> The new Security Considerations section in -03 seems to indicate that 
> the problem space may be constrained by properly utilizing certain 
> optional features of 7940. If that is correct, then perhaps the author 
> would consider revising the last part of the second paragraph to more 
> clearly state that?
>
The use of variants can make an LGR more robust, but that was not the 
>    of the label. When properly used, the label becomes unalterable and 
The intent was that by following certain conventions in drafting the LGR 
itself becomes more easily reviewable and the implementation more 
verifiable.

There are ways of defining variants, that while syntactically legal, are 
difficult to anticipate or impossible to implement unambiguously. 
Avoiding those cases by following the guidance here would result in an 
LGR that is "well-behaved", or predictable in its effects to the 
LGR-author (and reviewer) and implementable without running into 
potentially self-contradictory edge cases.

In any case, I doubt that it is in principle possible to make every 
label (no matter the script or language) "unalterable and observably 
verifiable", in fact, I don't know what that means.

Labels depend on unambiguous identification by the user, but not all 
users are equally discriminating or careful. Some will click on 
"gargle.com" -- nothing an LGR can do about that.

> this document.
Variants are an important part, but only  a part of an LGR design. There 
are other features of an LGR that the document does not give guidance 
on, if only to keep this document focused.
>
> ...ar enough with this technology to know if there is or isn't. If 
> there are no other issues, or they are far outside the scope of this 
> document, then don't worry about it.
>
I can check the text one more time to see whether there are some 
additional things that deserve to be mentioned.

A./
>     Thanks for the review, Chris. I should note that my document
>     shepherd review of the -02 version of this draft also produced
>     feedback about the need to add Security Considerations text. The
>     author added text and published the -03 version on 23 January.
>     Chris, could you please look at -03 and see how well the text
>     addresses your comments modulo what you’ve shared below? I assume
>     that you meant RFC 7940 (Representing Label Generation Rulesets
>     Using XML) when you wrote RFC 7948 (Internet Exchange BGP Route
>     Server Operations).
>
>     Scott
>
>     *To:* [email-masked] <mailto:[email-masked]>; [email-masked]
>     <mailto:[email-masked]>;
>     <mailto:[email-masked]>
>     I have reviewed this document as part of the security
>     directorate's ongoing effort to review all IETF documents being
>     processed by the IESG. These comments were written primarily for
>     the benefit of the security area directors. Document editors and
>     WG chairs should treat these comments just like any other last
>     call comments.
>
>     The document is well written and thorough but has no content in
>     the Security Considerations section. The guidance provided in this
>     INFORMATIONAL document appears to be sound but it should still
>     provide a statement of how this work attempts to address the
>     security concerns of RFC 7948. For perspective, the title of
>     section 12.1 of the Security Considerations section is "LGRs Are
>     Only a Partial Remedy for Problem Space".
>
>     My recommendation is that a Security Considerations section for
>     this document incorporate the Security Considerations section of
>     RFC 7948, along with statements of how the document addresses the
>     obtainable remediations, and what implementers should continue to
>     be concerned about.
>
>     Thanks,
>     Chris
>