[bess] Secdir last call review of draft-ietf-bess-mvpn-evpn-aggregation-label-10
Reviewer: Robert Sparks Review result: Has Nits 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 review comments. This document is mostly ready for publication as a Proposed Standard RFC, but has nits (one bordering on an issue) to address before publication. This document requires quite a bit of background provided outside of the document to make it meaningful. There is some effort to point to where essential concepts are defined, but a few more might be appropriate. It reads reasonably well, but I have provided some editorial comments at the end. Nit bordering on issue: The Security Considerations need more consideration. The essence of what's provided so far is "Nothing new to consider here, see RFC 5331, RFC 6514, RFC 7432, and RFC 8402 for the things you should really think about before using the procedures defined in this document". It's not clear how what the security consideration section in 5331 applies to these procedures - some discussion of what's important from that, and the other referenced docs, to _this_ document would be helpful. The primary concern seems to be entirely about the safe handling of, and consequences of (mis)-provisioning of, labels. Is there not a concise discussion in the literature around these labels to point to? Structural nit: The last paragraph and four bullets at the end of section 3.2 appears to be a set of pre-condition requirement (something that can only be violated by mis-configuration) rather than something to test for at runtime. Consider stating this earlier and as a requirement on configuration of the system. Or, if I'm incorrect, say what to do should a receiving PE encounter this configuration. Editorial nits: Consider more explicit instruction where you require PEs to program things. I think "place an entry in" or similar would be clearer. There is something that looks like normative text in the Terminology definition of SRGB (last sentence). Consider moving it into the body of the document, pointing to where it's specified (if specified elsewhere), or removing it. At "This document simply specifies" (in 2.1) - what does "simply" mean here? Please see if you can avoid the term. Consider rewriting the first sentence of 3.2 more directly (think about translation into other languages). Something like "The procedures here MAY be used when...". The "need not...unless" construction is difficult. At the last sentence of section 2.2 (before 2.2.1), consider how this will read in a decade. Avoid "today's networks" and simplify "more and more". Please break the single sentence paragraph at the end of page 12 (starting "When a PE receives an x-PMSI/IMEI") into several simpler sentences. Consider reworking the first part of "A PE MUST NOT both carry the DCB flag...". The route is carrying the flag, not the PE. ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
[bess] Cleaning up broken document entry in the datatracker
BESS, IESG, Bob - In May 2020, there was a submission of a draft named 'draft-wang-bess-evpn-mac-overload-reduction' that didn't finish the process, but internally some objects were created as if it did. Those objects are malformed, and are being removed. The draft was (as best I can tell) submitted successfully later under a slightly different name (-cmac- rather than -mac). Specifically, a Document object and a set of DocEvents were created but not properly constructed - no such objects should have been created at all until the draft finished the submission process, and these objects have now been removed. You should not notice any difference in the datatracker other than one page that 404s now rather than crashing. The Submission object remains documenting the incomplete submission. Please report any issues by replying to this mail. RjS ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
Re: [bess] Genart last call review of draft-ietf-bess-evpn-na-flags-05
Thanks for considering my suggestions Jorge - your edits address all my
concerns!
RjS
On 8/31/20 3:46 AM, Rabadan, Jorge (Nokia - US/Mountain View) wrote:
Robert,
Thank you very much for the review. Great points.
Please see in-line with [Jorge]. All the changes will be included in
the next revision.
Thank you!
Jorge
*From: *Robert Sparks via Datatracker
*Date: *Tuesday, August 18, 2020 at 6:11 PM
*To: *gen-...@ietf.org
*Cc: *draft-ietf-bess-evpn-na-flags@ietf.org
, last-c...@ietf.org
, bess@ietf.org
*Subject: *Genart last call review of draft-ietf-bess-evpn-na-flags-05
Reviewer: Robert Sparks
Review result: Ready with Nits
I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please treat these comments just
like any other last call comments.
For more information, please see the FAQ at
<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
Document: draft-ietf-bess-evpn-na-flags-05
Reviewer: Robert Sparks
Review Date: 2020-08-18
IETF LC End Date: 2020-08-28
IESG Telechat date: Not scheduled for a telechat
Summary: Ready for publication as a Proposed Standard RFC but with nits to
address before publication
The protocol being defined seems fine, and the IANA considerations are
well
constructed. I have a nagging feeling that there are new security
concerns this
introduces, but haven't been able to identify anything specific. I
appreciate
that the document discusses what happens when a bad-actor introduces
intentionally mis-configured flags.
Editorial Issues:
The Abstract is full of acronyms that are not universally understood,
and it
buries the point of the document. Please consider rewriting to focus more
specifically on the goal of the draft (see the introduction in the
shepherd's
writeup), keeping in mind that the abstract should make sense to
people who
don't know yet what PE stands for. Much of what you currently have in the
Abstract can be left to the Introduction. I expect a shorter (two or three
sentence) abstract will suit the document better.
[Jorge] we simplified the abstract as follows, hopefully it addresses
your comment:
Ethernet Virtual Private Network (EVPN) uses MAC/IP Advertisement
routes to advertise locally learned MAC and IP addresses associated
to host or routers. The remote Provider Edge (PE) routers may use
this information to populate their Address Resolution Protocol (ARP)
or Neighbor Discovery (ND) tables and then reply locally to ARP
Requests or Neighbor Solicitation messages on behalf of the owner of
the IP address. However, the information conveyed in the MAC/IP
route may not be enough for the remote PE to reply to local ARP or ND
requests. This document defines an Extended Community that is
advertised along with an EVPN MAC/IP Advertisement route and carries
information relevant to the ARP/ND resolution, so that an EVPN PE
implementing a proxy-ARP/ND function can reply to ARP Requests or
Neighbor Solicitations with the correct information.
In section 3.2: The list of three things in the list under "R and O Flags
processing" are all processing steps. But the list of 6 things under
"I Flag
processing" are not all processing steps. Please change the list to only
include processing steps, and move the examples and commentary to regular
paragraphs after the processing has been specified.
Consider moving the third top-level bullet in 3.2 ("MUST be ignored")
to be the
first bullet, and after that bullet say "otherwise".
[Jorge] ok, section 3.2 changed as follows:
3.2. Reception of the EVPN ARP/ND Extended Community
In addition to the procedures specified in [RFC7432] a PE receiving a
MAC/IP Advertisement route will process the EVPN ARP/ND Extended
Community as follows:
o The R, O and I Flags MUST be ignored if they are advertised along
with an EVPN MAC/IP Advertisement route that does not contain an
IP (IPv4 or IPv6) address. Otherwise they are processed as
follows.
o R and O Flags processing:
* If the EVPN MAC/IP Advertisement route contains an IPv6 address
and the EVPN ARP/ND Extended Community, the PE MUST add the R
and O Flags to the ND entry in the ND or proxy-ND table and use
that information in Neighbor Advertisements when replying to a
Solicitation for the IPv6 address.
* If no EVPN ARP/ND Extended Community is received along with the
route, the PE will add the default R and O Flags to the entry.
The default R Flag SHOULD be an administrative choice. The
default O Flag SHOULD be 1.
* A PE MUST ignore the received R and O Flags for an EVPN MAC/IP
Advertisement route that contains an IPv4->MAC pair.
o I Flag processing:
* A PE receiving an EVPN MAC/IP Advertisement route contain
[bess] Genart last call review of draft-ietf-bess-evpn-na-flags-05
Reviewer: Robert Sparks
Review result: Ready with Nits
I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please treat these comments just
like any other last call comments.
For more information, please see the FAQ at
<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
Document: draft-ietf-bess-evpn-na-flags-05
Reviewer: Robert Sparks
Review Date: 2020-08-18
IETF LC End Date: 2020-08-28
IESG Telechat date: Not scheduled for a telechat
Summary: Ready for publication as a Proposed Standard RFC but with nits to
address before publication
The protocol being defined seems fine, and the IANA considerations are well
constructed. I have a nagging feeling that there are new security concerns this
introduces, but haven't been able to identify anything specific. I appreciate
that the document discusses what happens when a bad-actor introduces
intentionally mis-configured flags.
Editorial Issues:
The Abstract is full of acronyms that are not universally understood, and it
buries the point of the document. Please consider rewriting to focus more
specifically on the goal of the draft (see the introduction in the shepherd's
writeup), keeping in mind that the abstract should make sense to people who
don't know yet what PE stands for. Much of what you currently have in the
Abstract can be left to the Introduction. I expect a shorter (two or three
sentence) abstract will suit the document better.
In section 3.2: The list of three things in the list under "R and O Flags
processing" are all processing steps. But the list of 6 things under "I Flag
processing" are not all processing steps. Please change the list to only
include processing steps, and move the examples and commentary to regular
paragraphs after the processing has been specified.
Consider moving the third top-level bullet in 3.2 ("MUST be ignored") to be the
first bullet, and after that bullet say "otherwise".
Editorial Nits:
I suggest deleting "refers to" in the terminology sentences. In all cases you
mean "is" and you don't need to say "is".
The last phrase in the description of Bit 4 at the end of section 2 was
difficult to read. Consider breaking the sentence into two or more.
At the end of section 3.1, "does not have any impact on" is confusing. I think
you mean "does not change"? At ", including" the sentence becomes awkward. I
suggest breaking that into a separate sentence. Perhaps "Specifically the
procedures for advertising ... are not changed."
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess
[bess] Secdir last call review of draft-ietf-bess-l2l3-vpn-mcast-mib-15
Reviewer: Robert Sparks Review result: Ready 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. This document is ready for publication as Proposed Standard RFC. This document provides a pair of MIB modules intended as building blocks for other MIB modules that will monitor/configure layer 2 and layer 3 virtual private networks supporting multicast. The MIB objects are all not-accessible or read-only. The security considerations section follows the guidance at <https://trac.ietf.org/trac/ops/wiki/mib-security>. The document had a thorough MIB doctor review. ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
