IESG Narrative Minutes
Narrative Minutes of the IESG Teleconference on 2017-09-28. These are not an official record of the meeting.
Narrative scribe: John Leslie, Susan Hares, and Ignas Bagdonas (The scribe was sometimes uncertain who was speaking.)
Corrections from: (none)
1 Administrivia
2. Protocol actions
2.1 WG submissions
2.1.1 New items
Telechat:
Telechat:
Telechat:
Telechat:
2.1.2 Returning items
2.2 Individual submissions
2.2.1 New items
Telechat:
2.2.2 Returning items
2.3 Status changes
2.3.1 New items
2.3.2 Returning items
3. Document actions
3.1 WG submissions
3.1.1 New items
3.1.2 Returning items
Telechat:
3.2 Individual submissions via AD
3.2.1 New items
Telechat:
3.2.2 Returning items
3.3 Status changes
3.3.1 New items
Telechat:
3.3.2 Returning items
3.4 IRTF and Independent Submission stream documents
3.4.1 New items
3.4.2 Returning items
4 Working Group Actions
4.1 WG Creation
4.1.1 Proposed for IETF Review
Telechat::
4.1.2 Proposed for Approval
Telechat::
4.2 WG Rechartering
4.2.1 Under evaluation for IETF Review
4.2.2 Proposed for Approval
5. IAB News We can use
6. Management Issues
Telechat::
Telechat::
7. Working Group News
7a. Other Business
1129 EDT Adjourned
(at 2017-09-28 06:00:02 PDT)
draft-ietf-tsvwg-ecn-experimentation
1) section 2 actually seems a bit redundant to me but I guess that not a
problem. I guess I would also be okay with the doc if section 2 would not be
there, but maybe this overview actually helps others who are less familiar with
ECN.
2) I guess it could actually be helpful to include a tiny bit of reasoning why
the ECN Nonce experiment is concluded instead of just saying that it was never
deployed and further point to an appendix of a draft (which is actually
appendix C and not B.1 I believe). I know this was discussed, but having one
sentence saying something in the lines like this is probably not to hard: "The
experiment is concludes with the result that ECN Nonce does not provide a
reliable integrity protection as the other end can always pretend to not
support this optional feature."
3) This sentence is a bit unclear:
"In addition, until the conclusion of the L4S experiment, use of
ECT(1) in IETF RFCs is not appropriate, as the IETF may decide to
allocate ECT(1) exclusively for L4S usage if the L4S experiment is
successful."
I guess the L4S exp RFC would use ECT(1), so the sentence to not really make
sense to me. Also given that there is no RFC for L4S yet, we actually don't
know if there is finally community/group consensus to publish that RFC. I guess
it actually to early to say something like this. I know why you want to have
this sentence in there, but from the processing point of view that does not
seems to be the correct thing to do and it might be better to just remove it.
Otherwise, if you want to keep it or something similar but maybe less
specific, following up on the feedback provided by IANA, the TCP flag should
probably be just marked as reserved with reference to this RFC.
4) I'm not certain about this part:
"An exception to this requirement occurs in
responding to an ongoing attack. For example, as part of the
response, it may be appropriate to drop more ECT-marked TCP SYN
packets than TCP SYN packets marked with not-ECT. "
Maybe it's to late here and that's the reason I don't get it, but what would be
the reason to rather drop ETC marked SYNs? Can you explain? I do understand
that there is no reason to not drop ECT-marked SYNs in an attack situation
(meaning don't try to mark, drop immediately) but I don't understand why you
should drop ECT-marked SYNs preferentially? If the assumption is that attacker
would more likely use ECN than non-attackers because the will usually not be
dropped but marked, I'm uncertain if that is true and still not sure if the
above recommendation is appropriate. In any case I think this needs at least
more explanation in the document.
5) As a side note on this sentence:
"Random ECT values MUST NOT be used, as that may expose RTP to
differences in network treatment of traffic marked with ECT(1) and
ECT(0) and differences in associated endpoint congestion
responses, e.g., as proposed in [I-D.ietf-tsvwg-ecn-l4s-id]."
I think random marking is anyway not a good idea because this is sometimes used
(incorrectly) as input for ECMP. Therefore I actually think the reference to
the l4s draft is actually not needed here.
Substantive:
General:
I agree with Ekr's comment specifying RFC updates as text"patches" is
confusing and unfriendly to the reader. While I don't necessarily agree that
we should do bis drafts instead, I hope people will remember that we never
actually render an "updated" RFC with the patches applied. I think this sort
of thing would be easier to understand if we just spoke of the changes at a
conceptual level and avoid getting wrapped around changing specific words to
other specific words. I don't expect that to change with this particular
draft, but I think the IESG should consider some guidance here. (And I fully
recognize that a lot of update drafts in ART do the same thing.)
-1, first paragraph: "An Experimental RFC MUST be published for any protocol
or mechanism that takes advantage of any of these enabling updates."
This seems like an odd use of 2119 language, at least for something other than
a BCP. Furthermore, I don't think this paragraph is the real authority on the
matter, since there is much more precise text scattered through the draft about
this particular requirement. Therefore, I suggest removing the 2119 language
and stating this descriptively. (e.g. "Mechanisms that take advantage of these
updates are to be specified in experimental RFCs.")
Speaking of which, there are several references to requiring experimental RFCs.
Are those expected to be IETF stream RFCs?
-5, first "patch":
Are there existing implementations that would become noncompliant with the new
text?
-9, 1st paragraph: "As a process memo that only removes limitations on proposed
experiments, there are no protocol security considerations."
I am skeptical that removing limitations from experiments can be assumed to be
security neutral on its face. Please consider documenting the thought process
that led to that conclusion.
Editorial:
-1, 2nd paragraph: " There is no need to make changes for protocols ...
I'm a bit confused--those hypothetical standards track RFCs will need to make
the sort of changes that this paragraph says are not needed. Is the point that
_this_ document does not need to make those changes?
-2, Congestion Response Difference: "As discussed further in
Section 4.1, an ECN congestion indication communicates a higher
likelihood that a shorter queue exists at the network bottleneck
node by comparison to a packet drop that indicates congestion
[I-D.ietf-tcpm-alternativebackoff-ecn]."
I'm not sure what is being compared here. Is it a high chance of shorter queue,
or higher chance of a short queue?
-- (same paragraph): "(next bullet)"
There are no bullets.
-2, Congestion Marking Difference:
The first sentence is hard to parse. Please consider breaking it into simpler
sentences.
-3, first paragraph: "As specified in RFC 3168, ... [stuff]... , as specified
in experimental
RFC 3540 [RFC3540].
This is hard to parse. In particular, I have trouble deciphering which part is
supposed to be specified in 3168 vs 3540.
-- 2nd paragraph: "but might equally have been due to re-
marking of the ECN field by an erroneous middlebox or router."
I think "erroneous" modified "re-marking" rather than "middlebox or router".
-4.2, 1st paragraph: "... prevent the aggressive low latency traffic starving
conventional
traffic ... "
Is there a missing "from" between "traffic" and "starving" Or maybe an "of"
after "starving"?
Below is Sue Hares' OPS DIR review. I would like to DISCUSS some points. I'm of
two minds. On one side, I read:
The scope of this memo is limited to these three areas of
experimentation. This memo expresses no view on the likely outcomes
of the proposed experiments and does not specify the experiments in
detail. Additional experiments in these areas are possible, e.g., on
use of ECN to support deployment of a protocol similar to DCTCP
[I-D.ietf-tcpm-dctcp] beyond DCTCP's current applicability that is
limited to data center environments. The purpose of this memo is to
remove constraints in standards track RFCs that stand in the way of
these areas of experimentation.
On the other side:
An Experimental RFC MUST be published for any protocol
or mechanism that takes advantage of any of these enabling updates.
Btw, the MUST is just plain wrong, as Ben mentioned.
So, if you go in the direction of providing requirements for the experiments
(as opposed to just removing the specification constraints), then I agree with
Sue. The document title goes in the direction: if it would say something such
as "Removing constraints to the ECN experimentation", that would be a different
story.
Reviewer: Susan Hares
Review result: Has Issues
This is an OPS-DIR Review which focus the work on issues in deployed technology
based on this RFC.
Summary: Has issues as guide to experimental RFC . To me these operational
issues General comment: Thank you david for addressing this Area. Better ECN
control is critical to many portions of the network.
My comments on this draft are because I
really hope you can do quality experiments.
How this might be resolved: if there is a operational guidelines section (or
separate document), that covered: a) how to set-up and determine if a ECT(1)
experiment success or fails b) how to manage your ECT(1) experiment in your
network. c) how to manage and detect if your ECT experiment is running into
problems with other IETF technology (TRILL, MPLS VPNs, IPVPNs, BIER and NV03
technology). d) Recommending a monitoring structure (e.g. yang modules,
netconf/restconf and monitoring tools0
Major issues:
#1 There is nothing in this document which provide guidelines to the authors of
experimental RFCs based in this draft on specific ways to
monitor the ECN experiments, report the ECN experimental data, or disable
the experimental data. If the success or failure of an experiment is
based on "popular vote" determined by deployment, then say state this
point. I personally would object to that
because you cannot tell if a limited experiment in a specific location (E.g.
a data center) might be successful in another location.
If the success or failure of an experimental RFC is based on a specific set
of criteria for ECN, then it would be good to give an operational suggestion
on how to: a) design an experiment, b) run an experiment and collect data,
and c) report ths
data in order to standardize the ECN experiments using ECT(1).
page 10 section 4.2 last 2 paragraphs in sentence, hinted that you have an
experiment in mind without specifying the experiment's success or failure
criteria other than popular vote. Is this true? if it is, this is
problematic. If I misunderstood your text, then please
have someone re-read the text.
I have read lots of papers on ECN.
2) No discussion was given on how the TCP layer experimentation would impact
routing layer handdlng of ECN.
For example, the trill WG has the draft draft-ietf-trill-ecn-support.
Automated tunnel set-up for MPLS VPNS or IP VPNS may look at the ECN ECT(0) or
ECT(1). TRILL's ECN supports the layer-2 within the data centers. Some IP
VPNS or MPLS VPNS may be needed for the data-center to business site
or data-center backup traffic.
As written, this draft allows loosening of the RFC3168 draft but does not
provide guidelines for network interaction.
3) Some networks also use the diff-service markings to guide traffic in the
network.
This document does not suggest an operational check list on how to design
an experiment that supports or does not support these markings.
4) Modern operational IETF protocols and data modules for automating the
tracking of these experiments should be suggests
And again, I can only agree with Sue's comment below, as stressed by Ekr and Ben also. However, this point was answered by Spencer and Mirja, so let's move on. Editorial: Some reviews have hinted that the text is repeats several sets of language. People have found this lacked clarity. One wonders why the authors did not simply provide a set of bis documents for RFC3168, RFC6679, RFC 4341, RFC4342, and RFC5622 if it is just updating the language in the specifications. This document tries to be both revision of the specifications and the architectural guidelines for experiments. The dual nature does not lead to clarity on either subject.
Having a document which is sort of a verbal patch on another document is pretty
hard to read. I recognize that this seems to be customary in some areas, so I'm
not marking this as DISCUSS, but I really wish you would do a bis instead.
INLINE COMMENTS
Line 98
This memo updates RFC 3168 [RFC3168] which specifies Explicit
Congestion Notification (ECN) as a replacement for packet drops as
indicators of network congestion. It relaxes restrictions in RFC
Replacement or additional indicator?
Line 164
that for congestion indicated by ECN, a different sender
congestion response (e.g., reduce the response so that the sender
backs off by a smaller amount) may be appropriate by comparison to
nit: reducing
Line 170
couples the backoff change to Congestion Marking Differences
changes (next bullet). This is at variance with RFC 3168's
requirement that a sender's congestion control response to ECN
I'm having a lot of trouble reading this sentence. It seems like you are
comparing the ECN response to a lost response, but these other two drafts also
are about a less aggressive response. Perhaps this would be clearer as:
"indicated by loss. Two examples of such a reduced response are..."
Section 3 ends with the following text: Additional minor changes remove other mentions of the ECN nonce and implications that ECT(1) is intended for use by the ECN nonce; the specific text updates are omitted for brevity. I'm not sure I follow what's meant here. Is this basically saying "there are other, less substantive edits required to RFC 3168, but those changes are left as an exercise for the reader"? [Sorry for the additional noise, but I noticed one more issue that you'll want to correct] Section 9 says "See Appendix B.1 of [I-D.ietf-tsvwg-ecn-l4s-id] for discussion of alternatives to the ECN nonce." I beleive that this should refer to Appendix C.1 rather than Appendix B.1.
I found section 2 to be useful.
draft-ietf-teas-rsvp-te-scaling-rec
I agree with Ben that it is not clear which recommendations are from this document and which ones are restatements from other documents. Some of these recommendations originating from this document look like they might be updating RFC2961. Why does this draft not update RFC2961 formally? It was not immediately apparent from the shepherd write up if the WG had considered this.
I'm uncertain what section 2.1.3. actually recommends. My understanding is that it is recommend to still retransmit some message even if the Rl was reached and to do that every 30s basically forever. First of all I think this still needs a termination criteria when to stop to try to retransmit finally. And then I don't understand why this is needed, instead of e.g. just using a larger Rl value? Can you please clarify!
I fully agree with the gan-art review (Thanks Elwyn!) and Alvaro, that this reads from time to time like a BCP but is actually an extension specification. I would strongly recommend to apply the changes proposed by the gen-art review, and there is also a very detailed list of nits/edits that should probably be applied. Please have a look at that!
[Note: The authors revised this draft between the time I reviewed it and transcribed my notes. This is a review of version 06. I will not have time to re-review 07 prior to the telechat to see if my comments still apply.] Substantive: - General: I agree with the "major issues" comments from Elwyn's Gen-ART review. - General: There's a fair amount of 2119 language in this draft that refers to options in prior RFCs. It's not clear which of those are new normative requirements vs restatements of existing requirements. In the former case, this draft would need to update those respective RFCs. In the latter case, this draft should use descriptive language rather than 2119 keywords (unless in the form of direct quotes.) -1, last paragraph: "In order to reap maximum scaling benefits, it is strongly RECOMMENDED that implementations support both the techniques." That statement seems to require updating ... something. Maybe 3209 or 2961? -2.1.3, 2nd paragraph: Does this update RFC 2961? Or if not, is the normative language appropriate here? -2.2, bullet list: Are these new normative requirements or restatements of existing ones? -6: "This document does not introduce new security issues." Please document the reasoning behind that statement. Editorial: -2.1, section title: Why the quotes? -2.2, first bullet: Section 1 already normatively states these. This text effectively says "MUST follow the MUSTs...". (Note that this pattern recurs in several places.) -2.3, first paragraph: "The set of recommendations discussed in this section..." As written, many of those are requirements rather than recommendations.
I'm confused by this SHOULD. The configurable periodic retransmission interval for this slower timer SHOULD be less than the regular refresh interval. Could you help me understand why someone would want to set the "slower timer" to be shorter than the regular refresh timer?
I have some reservations around certain aspects of the document, but they've largely been captured by other IESG members. I'll reiterate two of them here, phrased as concrete suggestions. Change the title to something more like "Protocol Enhancements to Improve...", and rephrase all uses of the word "recommendation" to instead refer to the techniques described in the document. Clarify that the retransmission of messages described in section 2.1.3 does not continue for years or decades: specify a limit after which retransmission ceases even without an ACK. Please expand the following acronyms upon first use and in the title; see https://www.rfc-editor.org/materials/abbrev.expansion.txt for guidance. - RSVP-TE - RSVP Traffic Engineering - LSR - Label Switching Router
(1) This document seems to do two things: make a series of rfc2961
recommendations, and introduce a couple of new techniques. What is not clear
to me is whether the first part is independent of the second. Will the
implementation of Section 2.1. ("RFC2961 Specific" Recommendations) provide
scaling benefits on their own (i.e. without the new techniques)? If so, please
add some text (maybe in the Introduction) to indicate that.
(2) As for as the new techniques, it is confusing to me the use of rfc2119
language in Section 2.1.1. (Basic Prerequisites), which reads:
An implementation that supports the techniques discussed in Sections
2.2 and 2.3 must meet certain basic prerequisites.
...
o It SHOULD initiate all RSVP Refresh Overhead Reduction mechanisms...
I know that the leading "must" is not an RFC2119 keyword, but it may be
confusing with the "SHOULD" used later...specially because it sounds as if (in
some cases) it may be ok to not "initiate all RSVP Refresh Overhead Reduction
mechanisms" and still use the new mechanisms described later. What are those
cases? Maybe the mandatory prerequisites should all be listed in the same
sub-section, while other recommendations can be elsewhere.
Note also that later in 2.2 and 2.3 the text says that an implementation "MUST
support all the recommendations" in 2.1. What does that MUST mean if one of
the recommendations is not an absolute requirement?
(3) Section 2.1.2 (Making Acknowledgements Mandatory) seems to also be a
prerequisite, right? At lease the text says that "an implementation that
supports the techniques discussed in Sections 2.2 and 2.3...MUST...". The fact
that it is not in the actual prerequisites section may be confusing to some.
(4) Section 2.1.3. (Clarifications On Reaching Rapid Retry Limit (Rl)) is (by
clarifying and using normative language) making specific changes to rfc2961.
Assuming that there is value in 2.1 being used by itself (without the new
techniques), why isn't there a formal Update of rfc2961?
(5) This reminds me, please use the new RFC2119-related template: please take a
look at rfc8174.
Nits:
s/interval interval/interval
When defining the new capability advertisements (in 2.2.1 and 2.3.1), it would
be nice to include a reference to rfc5063.
Given the specification in the preceding sections, I think that 2.2.2 and 2.3.2
are superfluous.
It would be nice to point at the Appendix from the main text.
draft-ietf-sfc-nsh
Thank you for responding to Wes Eddy's TSV-ART review of -19 (and, of course, for making text changes that seemed appropriate). It seems to me that you describe expectations about the applicability of NSH in various places in the document, and in various ways. You might consider (for example) pulling the common elements of statements like (from Section 5) Within a managed administrative domain, an operator can ensure that the underlay MTU is sufficient to carry SFC traffic without requiring fragmentation. Given that the intended scope of the NSH is within a single provider's operational domain, that approach is sufficient. and (from Section 8) NSH is designed for use within operator environments. As such, it does not include any mandatory security mechanisms. As with many other protocols, without enhancements, the NSH encapsulation can be spoofed and is subject to snooping and modification in transit. However, the deployment scope (as defined in [RFC7665]) of the NSH encapsulation is limited to a single network administrative domain as a controlled environment, with trusted devices (e.g., a data center) hence mitigating the risk of unauthorized manipulation of the encapsulation headers or metadata. This controlled environment is an important assumption for NSH. There is one additional important assumption: All of the service functions used by an operator in service chains are assumed to be selected and vetted by the operator. into one section describing the applicability of NSH, appearing MUCH earlier in the document (the most detailed description of your expectations looks like it appears in the Security Considerations section, but parts of that description are applicable to the Fragmentation Considerations section, which appears three sections earlier in the document). The reader would have your intended applicability in mind much earlier and more clearly, and you could just invoke your expectations by reference when you need to explain how they apply elsewhere in the document, so the expectations in play would be consistent across mentions throughout the document. I'm still bothered that this document doesn't explicitly mention ICMP blocking as a problem for PMTUD with IP encapsulations. We're just not good at path MTU discovery, so it seems useful to call this out explicitly when a document expects to use PMTUD. That way, people who use NSH will know to check for ICMP blocking on their networks before they receive their first trouble reports. This almost reached my threshold for balloting Discuss, so I'd hope you folks would consider that. I see that the applicability of NSH includes encapsulations that don't provide a path MTU discovery mechanism, and that your resolution for those encapsulations is to log events when a "too big" packet is dropped. Could you educate me, as to whether all encapsulations detect that this is happening? It might be that encapsulations are using a fixed maximum MTU by definition, so that what you're logging is an attempt to send a payload that violates the protocol definition of the encapsulation, but I don't know that that's true in all cases, so thought I should ask. I saw a suggestion from Joe Touch (in a response to the TSV-ART review) to consider looking at the terminology developed for draft-ietf-intarea-tunnels. I didn't see a reply to that suggestion, and I didn't see a reference to draft-ietf-intarea-tunnels in -24 - was this considered? (I'm also asking because I want to keep track of whether people applying encapsulations find that document useful, of course) (Joe's follow-up is at https://mailarchive.ietf.org/arch/msg/tsv-art/CsdWwR9B5_AB64D0eFl-KIE7_NA)
I provided long (and somewhat grumpy!) comments on the previous version of this document -- I'd like to thank the authors, especially Carlos for addressing them. This version is, IMO, much improved.
* Section 5 I think the fragmentation part is underspecified. Take an example where IPv6 is used as the transport encapsulation. If the packet needs to be fragmented, will the NSH header be duplicated into each fragment? If so, this is new behavior for IP that will treat this like any other payload. If not how will the subsequent fragments be treated on the service path?
* Section 1.2. The definition of metadata seems to point to RFC7665 but the definition that follows does not match the definition from RFC7665. * Section 2.2 What does a "Next Protocol" with the value of 0x4 (NSH) mean? Does the NSH allow nesting. How will such system work? * Section 3 "The O bit, as well as unassigned flags, MUST be copied transparently from the old NSH to a new NSH." If there is reclassification, why is there an assumption that an OAM packet cannot be reclassified into a non OAM packet since a new NSH header is being inserted? * Section 8.1. Not sure what the reference to BCP38 means here. Is it for checking the source addresses the inner header that is getting encapsulated inside the NSH header? Or is it for the transport encapsulation header. Either way it is not clear what this entails. Please clarify. * Section 11.1 This section mentions that ethertype 0x894F has been allocated for NSH. Are there any other transport encapsulations planned? If not, I would recommend tightening the text around the transport encapsulations until other encapsulations are more well defined. e.g. How does the UDP transport encapsulation referred in the example work?
I have a couple of comments on the design. I know, as always in IESG review state, it's probably too late to make any changes to the actual header format, therefore most of my comments are actually in the comment section below. I still decided to note them so at least people can consider these points. However, there are a few things that I need clarification for before publication, which I note in this section: 1) Sec 2.2 "SF/SFF/SFC Proxy/Classifier implementations that do not support SFC OAM procedures SHOULD discard packets with O bit set, but MAY support a configurable parameter to enable forwarding received SFC OAM packets unmodified to the next element in the chain. Forwarding OAM packets unmodified by SFC elements that do not support SFC OAM procedures may be acceptable for a subset of OAM functions, but can result in unexpected outcomes for others; thus, it is recommended to analyze the impact of forwarding an OAM packet for all OAM functions prior to enabling this behavior. The configurable parameter MUST be disabled by default." This part is really unclear to me and I believe needs to be further specified. Where should this configurable parameter be? In the Context header? Why don't you just use one of the unassigned bit to indicate if an unknown (OAM) packet should be forwarded or not? Moreover, I also disagree with this text. If there is a bit/a way to indicate if a not supported OAM packet should be forwarded or not, it should just be defined like this, while any considerations if that bit should be set or not depend on the OAM function itself and do not need to be discussed here. Finally, it is not well explained what an OAM packet is at all. Is that a 'fake' packet that is generated by the operator to actively test the (potentially newly configured) SFP? If so, why does a SF need to know if a packet is an OAM packet or not? Usually it's a bad idea to use different kind of traffic for testing compared to what will be used in operations. Please provide more explanation here! 2) section 2.4 "An SFC-aware SF MUST receive the data semantics first in order to process the data placed in the mandatory context field. The data semantics include both the allocation schema and the meaning of the included data. How an SFC-aware SF gets the data semantics is outside the scope of this specification." This is really confusing to me. I think this is what you need an actually data semantics aka type field for in the base header. Or is there an actual reason to not put this information directly in the base header where it is need but instead assuming some magical way this information may take to reach the node? If the assumption is that the SF is configured to know based of the SFI what the content of the context header has to be, you a) need to say that in the draft, and b) that's really error-prone because it's really hard to tell if the conext header actually holds the information that you need or just random crap (of course depending of the expected data type of this information). In short, I think you really need a type field somewhere here. In any case, you really need to explain this more! Also, the text further says: "An SF or SFC Proxy that does not know the format or semantics of the Context Header for an NSH with MD Type 1 MUST discard any packet with such an NSH..." How does the SFC proxy know that it knows the format or not if there is no type field or identifier that indicates what the format should be? Also, a related question from me: why is the context header present in all types of NSH if there is no use for it defined in this document yet? Why is there no fixed length NSH without a context header then? 3) Section 2.5.1: "If multiple instances of the same metadata are included in an NSH packet, but the definition of that context header does not allow for it, the SFC-aware SF MUST process the first instance and ignore subsequent instances." This seems error prone to me. If the same metadata appears multiple where it should not, that seems clearly like an error case for me. Just using the first one and proceed normally might not be the right thing to do. In any case I think such an occasion should at least be logged. If the multiple instances are just a copy of each other and carry the same information, it's probably okay to use that information and proceed. If the different instances carry different information, it maybe a bit dangerous to just use the first one and ignore others silently. In this case I would rather recommend to drop the packet... 4) In line with the second comment from the tsv-art review (thanks Wes!), I don't really understand why this documents says (sec 6) that there can be multiple next hops for the same SFP or SFs can be traversed in a different order. May understanding (from a quick look at RFC7665) would be that, if those things are needed e.g. for load balancing, then one should define different SFPs and the Classifier must have the knowledge that two SFP are equivalent and select them respectively. The reason why I'm really concerned about this is that usually a number of packets below to a flow and all packets belonging to the same flow just ideally take the same route. But usually only the Classifier has a notion of what a flow is and respectively will assign the SFI to the packets belonging to the same flow. If now any SF on the path can more or less randomly decided to forward packet belong to the same flow to one or another next nodes, I would assume that this is not only a problem for the flow, e.g. reordering, but also for SF itself in many cases.
Further considerations: 1) I don't really see why a TTL in the base header is needed. I mostly understand why there is the Service Index in service header, also I think there should be better mean to validate that you SFP is correct and I ideally you should really not need this. However, loop prevention can be provided by both mechanism and moreover there is probably also often a TTL in the encapsulation protocol and loop prevention should really be a function of that forwarding protocol and not the NSH. 2) I don't see why you need the type field in the base header. This is fully redundant because because all you need is the length field. If the length is 0x2 it is what you have defined as type 1 if the length field is larger it is type 2. I also don't see the need for any other types in future because you also have the version field; if you need anything else you should go or probably have to go for a new version. Note that the general probably with unnecessary redundancy is that is add complexity. If you keep this redundancy you have to separately handle and implement the case(s) where the type is 1 but the length is larger than expected. If at all you could probably just use one bit to indicate that the length field is present and if not the length is 0x2. However, saving bits does not really seem to be a concern for you, so that might not actually be an advantage. 3) sec 2.5.1 "Unassigned bit: One unassigned bit is available for future use. This bit MUST NOT be set, and MUST be ignored on receipt." Is there an actual reason to have an unassigned bit here? Because I would assume that the type already provided enough flexibility for way to extend the metadata format in any way needed. 4) Also section 2.5.1: " Length: Indicates the length of the variable metadata, in bytes. In case the metadata length is not an integer number of 4-byte words, the sender MUST add pad bytes immediately following the last metadata byte to extend the metadata to an integer number of 4-byte words. The receiver MUST round up the length field to the nearest 4-byte word boundary, to locate and process the next field in the packet." Your definition of the length field might be more error-prone than needed. It would probably be easier to simply define the length as 4-byte words, and the type of course defines the content of the metadata field and as such can simply define which part of the total metadata field holds certain data of a certain type and with part is padding. 5) And finally I have to say it is unclear to me why the SFI and SI field are described as a separate header. Given they have to be present in all SFH, I would consider them as two fields of the base header. But it is after all really just an editorial issue. However, all this together with my previous comments makes the protocol spec actually much more complicated than it needs to be... 6) I also have to agree to the last comment of the tsv-art review: I think it would have been nicer to not only described the NSH but also define mappings to a set of possible encapsulations because I would assume that for each encapsulation there are a couple specific considerations that need to be made to make things work successfully. I don't think that all encapsulations can be captured by general consideration and I cannot make up my mind to go through all cases in my head to figure out if there are things that needs to be noted.
Substantive: - General: This is a mechanism to add metadata to user flows. There is very little discussion about how that metadata may relate to the application layer payloads. It's likely that some of those payloads will be encrypted by the user in an attempt to control what information is shared with middleboxes. I'd like to see some discussion about how this relates to the guidance in RFC 8165. (Note: I am on the fence about whether this should be a DISCUSS. But since "on the fence" is probably insufficient grounds for a DISCUSS, I'm leaving it as a comment.) - General: I support Kathleen's DISCUSS points concerning integrity protection. The document leaves that up to the transporting protocol. I think it's reasonable to recommend that that protocol at least default to providing integrity protection unless there's a good reason not to. -2.2, "version": How is the version field to be used by consumers? That is, what should a recipient do if the field contains a version number it doesn't support/recognize? -2.2, MD type 0x0: "Implementations SHOULD silently discard packets with MD Type 0x0." Why not MUST? -- MD type 0xF: "Implementations not explicitly configured to be part of an experiment SHOULD silently discard packets with MD Type 0xF." Why not MUST? -2.2, Next Protocol Values: Why are there 2 experimental values? (as opposed to 1, or, well, 3). -2.3, last paragraph (and several other places): This draft seems to take a position that a failed SFP means the service level flow fails. Are there no use cases where delivery of the service flow is critical and should happen even if the chain of middleboxes fails? -2.4, paragraph starting with "An SFC-aware SF MUST receive the data semantics..." I'm not sure what the intent of this paragraph is. Is that MUST really a statement of fact? Or is there really and expectation of an out-of-band delivery of some semantic definition? -3, list item 1: "A service classifier MUST insert an NSH at the start of an SFP." What if an initial classifier receives a packet that already has an NSH? Can multiple NSHs be stacked? -7.1, last paragraph: "Depending on the information carried in the metadata, data privacy considerations may need to be considered. " "may need to be considered" is weak sauce. Data privacy always needs to be considered, even if the _output_ of that consideration is that there is nothing sensitive being carried. Please consider dropping the "may". Also, this seems like an odd place to bury a privacy discussion. Please consider moving this to a "Privacy Considerations" section. -8, first paragraph: It seems like insider attacks are worth at least a mention when discussing a single operator environment as a mitigator against attacks. -8.1, 2nd paragraph: This doesn't seem like a single operator scenario, in the sense that part of the flow crosses a network that is not controlled by that operator. -8.3, 4th paragraph: Please elaborate on what is meant by "obfuscating" subscriber identifying information (as opposed to "encrypting" or "leaving it out in the first place".) Editorial: -2.2, "O bit", last paragraph: "The configurable parameter MUST be disabled by default." Does "disabled" mean "unset" (or "set to zero")? -2.2, "unassigned bits": "At reception, all elements MUST NOT modify their actions based on these unknown bits." Isn't that MUST NOT just a restatement of the "MUST ignore" from the previous sentence? There's no problem with reinforcing a point, but there shouldn't be multiple instances of the same 2119 requirement. Also, would logging a warning violate the "MUST NOT modify their actions/MUST ignore" requirement? -8, first paragraph: "NSH is designed for use within operator environments." Is there a missing "single" before "operator"?
(1) While describing the MD Type field, Section 2.2. (NSH Base Header) talks about the specific scenario in which "a device will support MD Type 0x1 (as per the MUST) metadata, yet be deployed in a network with MD Type 0x2 metadata packets", and it specifies that "the MD Type 0x1 node, MUST utilize the base header length field to determine the original payload offset if it requires access to the original packet/frame." This is the case where the node in question *does not* support MD Type 0x2, right? If so, then the specification above seems to go against (in the last sentence of the same paragraph): "Packets with MD Type values not supported by an implementation MUST be silently dropped." IOW, if the node doesn't support 0x2, why wouldn't it just drop the packet? (2) Section 2.5.1. (Optional Variable Length Metadata) says that this document "does not make any assumption about Context Headers that are mandatory-to-implement or those that are mandatory-to-process. These considerations are deployment-specific." But the next couple of paragraphs specify explicit actions for them (mandatory-to-process): Upon receipt of a packet that belongs to a given SFP, if a mandatory- to-process context header is missing in that packet, the SFC-aware SF MUST NOT process the packet and MUST log an error at least once per the SPI for which the mandatory metadata is missing. If multiple mandatory-to-process context headers are required for a given SFP, the control plane MAY instruct the SFC-aware SF with the order to consume these Context Headers. If no instructions are provided and the SFC-aware SF will make use of or modify the specific context header, then the SFC-aware SF MUST process these Context Headers in the order they appear in an NSH packet. Maybe I'm confused about considerations being deployment specific vs specifying what to do here. Can you please clarify? (3) "SFFs MUST use the Service Path Header for selecting the next SF or SFF in the service path." Section 6 explains most of what has to be done -- what I think is still not clear in this document is where the information in Tables 1-4 comes from. There may be different ways for an SFF to learn that, and I would imagine that it is out-of-scope of this document. Please say so -- maybe there's a relevant reference to rfc7665 (?). (4) Section 11.1. (NSH EtherType) seems out of place in this document because (1) the document doesn't discuss the transport itself, and (2) it is in the IANA section... (5) What is the "IETF Base NSH MD Class" (Section 11.2.4)? Ahh, I see that Section 11.2.6 talks about "the type values owned by the IETF"; it would be good to say that MD Class 0x0000 is being assigned to the IETF (in 11.2.4). Nits: In section 2.2. (NSH Base Header), it would be nice to have a forward reference when the Service Index is first mentioned. It may be nice to explicitly state in the description of the MD Type field (Section 2.2) that for length = 0x2 and MD Type = 0x2, there are in fact no optional context headers. (I know there's some text about this later in section 2.5.) "...all domain edges MUST filter based on the carried protocol in the VxLAN-gpe". That "MUST" is out of place because the text is an example.
First, I'd like to thank the authors and WG for your efforts in recent
revisions of this draft, it has come a long way. I still want to poke at the
lack of a requirement for either integrity protection on the NSH itself or for
MUSTs on protections from the transport encapsulation. Attacks inside of a
data center or single operator domains happen all too often. The number from
2016 is up 164% as of a statistic I saw earlier today. We can't srug this off
anymore.
Security Considerations section:
First two sentences say:
NSH is designed for use within operator environments. As such, it
does not include any mandatory security mechanisms.
I think you intended the first sentence to say, "within a single operator
environment" as what you have now could be multiple networks managed separately
with that statement. Then for the second sentence, I know you don't have an
integrity mechanism mandated, but I really think one should be. Couldn't the
path be altered and not detectable if there is no integrity checking? This
could be used to avoid security protections or to route it inappropriately
through a multi-tenant environment. Sure, the underlying protocol should
provide session encryption on application traffic, but there's no reason why
security shouldn't have been baked into this protocol as a requirement.
From the architecture document, the security considerations section calls
attention to possible issues related to lack of integrity checking. Since no
encapsulating transport is specified with required session encryption, and the
NSH addition doesn't have integrity protection, how will you meet this
architecture requirement from RFC7665:
Service Overlay: Underneath the service function forwarders, the
components that are responsible for performing the transport
forwarding consult the outer-transport encapsulation for
underlay forwarding. Used transport mechanisms should satisfy
the security requirements of the specific SFC deployment. These
requirements typically include varying degrees of traffic
separation, protection against different attacks (e.g.,
spoofing, man-in-the-middle, brute-force, or insertion attacks),
and can also include authenticity and integrity checking, and/or
confidentiality provisions, for both the network overlay
transport and traffic it encapsulates.
It seems from this text, something should be specified for the transport
encapsulation.
From the text in the draft under review:
As with many
other protocols, without enhancements, the NSH encapsulation could can be
spoofed
or otherwise modified and is subject to snooping and modification in transit.
However, the deployment scope (as defined in [RFC7665]) of the NSH
encapsulation is limited to a single network administrative domain as
a controlled environment, with trusted devices (e.g., a data center)
hence mitigating the risk of unauthorized manipulation of the
encapsulation headers or metadata.
This is in direct conflict with the Service Overlay requirements in the
Security Considerations of RFC7665.
Section 8.1
I'd like to see some MUSTs to address the concerns listed in RFC7665 for
encapsulation requirements or an addition of integrity protection on NSH itself.
This introductory text is much improved from a previous version and my comments, thanks for the update. This helps quite a bit. The Network Service Header (NSH) specification defines a new protocol and associated encapsulation for the creation of dynamic service chains, operating at the service plane. The NSH is designed to encapsulate an original packet or frame, and in turn be encapsulated by an outer transport encapsulation (which is used to deliver the NSH to NSH-aware network elements), as shown in Figure 1: Section 8.1: I don't think you need the text on BCP38. It's a helpful recommendation in general, but I don't see how it's directly applicable to this specification. Thank you for adding the text on Boundary protections per the SecDir review, I think this is very helpful.
I concur with Kathleen's DISCUSS. To state my view of things: 1. The assumption that the datacenter is a secure environment is not a reasonable one. As Kathleen and Adam both observer, datacenter breaches are common and that is why people are moving towards encryption inside the data center. I see that this draft has text claiming that this is only to be deployed in safe environments, but we know that technologies like this get deployed outside the locations for which we claim they are to be deployed, and there's nothing here to stop that. Moreover, the whole trend towards cloud computing pushes us away from designs in which you can safely talk about single secure zones. 2. The text in S 8.1 about how you might want to use some kind of transport security does not seem sufficient. As above, we know that if we don't specify something, people will deploy this technology in insecure settings without any kind of security. I concur with Kathleen's point that this document should provide built-in security mechanisms rather than just punting to the under-layer. Given that as S 1 makes clear, all these SFs are part of the same administrative domain, this seems like a comparatively less challenging setting. If there is some reason why that's infeasible, that needs to be explained.
Line 143
| Original Packet / Frame |
+------------------------------+
Nit: I would have expected this stack to go the other way, with TE on the
bottom.
Line 165
overlay domain using virtual connections and tunnels. A corollary is
that a network administrative domain has a well defined perimeter.
This is not a reasonable assumption in modern datacenter environments,
especially if you have virtualized services.
Line 372
1 prior to NSH forwarding lookup. Decrementing by 1 from an incoming
value of 0 shall result in a TTL value of 63. The packet MUST NOT be
forwarded if TTL is, after decrement, 0.
I am having trouble following this, Is the point that I can emit a packet with
TTL 0, which is effectively TTL 64?
Line 375
This TTL field is the primary loop prevention This TTL mechanism
represents a robust complement to the Service Index, as the TTL is
Nit: "prevention mechanism. This"?
Line 379
better, although not perfect, interoperation with pre-standard
implementations that do not support this TTL field.
This point would be clearer if it were made before the rule about decrement.
Line 403
0x0 - This is a reserved value. Implementations SHOULD silently
discard packets with MD Type 0x0.
Why is this a SHOULD and not a MUST? That seems like it will create potential
interop problems.
Line 651
encapsulated packet. It is therefore the last node operating on
the service header.
Can you also nest NSHs?
I have the same concern as Kathleen's DISCUSS, and would have blocked the draft
on the same grounds if such a position were not already in place. The "crunchy
perimeter, soft center" model of security was flawed to start with; and, even
in those arenas where it was once fashionable, it's starting to be considered
dated (e.g., much of the traffic inside data centers is secured using TLS --
see the recent discussions in the TLS working group for evidence of this
situation). More notably, this "unconditionally trusted network zone" approach
to security has led to some spectacular exploits recently (cf.
https://www.wired.com/2016/04/the-critical-hole-at-the-heart-of-cell-phone-infrastructure/).
Rather than explicitly fostering this model, the security section really needs
to normatively disallow it.
(n.b., I reviewed version -21 of the document -- but I don't find the changes
between that version and -24 to address the issue Kathleen raises)
----
Section 3 says the following about reclassification behavior:
When the logical classifier performs re-
classification that results in a change of service path, it MUST
replace the existing NSH with a new NSH with the Base Header and
Service Path Header reflecting the new service path information
and MUST set the initial SI. The O bit, as well as unassigned
flags, MUST be copied transparently from the old NSH to a new
NSH. Metadata MAY be preserved in the new NSH.
I don't see anything here about copying the TTL. If the TTL isn't copied, you
can end up with a stable (and unending) loop involving two classifiers (which
seems even more damaging than usual, as the SI value won't generally survive a
reclassification, right?). I would suggest adding "TTL" to the list of things
that MUST be copied when reclassification occurs.
I am agreeing with Kathleen's DISCUSS. Also, have you thought about likelyhood of introducing new versions, and if it is likely, what kind of restrictions do you want to impose on future versions (e.g. requirements on backward compatibility) and what are the criteria for bumping the version number? For example, future versions must use the same Base Header and Service Path header, but can add new mandatory fields after that. Etc.
draft-ietf-dcrup-dkim-usage
-4: "Verifiers MUST verify using rsa-sha256." Should this say "...MUST be able to..."? That is, am I correct in assuming that a verifier will use the scheme specified by the signer if it is capable of doing so, and that it doesn't make sense to try to verify with rsa-sha256 if the signer used something else?
Thanks for your response to the SecDir review and addressing the problem in another draft. https://datatracker.ietf.org/doc/review-ietf-dcrup-dkim-usage-04-secdir-lc-nystrom-2017-09-20/
I would have expected section 4 to be explicit in the interaction between the requirement that "rsa-sha1 MUST NOT be used for signing or verifying" and the Authentication-Results header defined in RFC 7001. In particular, I would have expected to see guidance here whether receipt of a message using sha1 should be coded as "neutral" or "policy": as an implementor, I would be unsure which one to use.
Please check and address the feedback provided by the gen-art review (Thanks Jari!). My understanding is that the normative language was discussed in detail for this draft but Jari brought up a point on forward-comparability with future algorithms regarding verification. I would also be interested to at least see a reply to that!
draft-baeuerle-netnews-cancel-lock
I have some comments and nits, but please keep in mind that I'm really not a
new expert, so apologies if some of these are obvious.
Section 1. Introduction
"or injecting agent that processed the original article has required to
withdraw it via the use of a cancel control article" I think that this is
actually "requested", not "required" --AFAICT, the person doing this cannot
really enforce that this is done, and so the best that they can do is request
that this happens. Or, if they really can, perhaps "... that processed the
original article is withdrawing it via the use of a cancel control article".
"One property of this system is that it prevents tracking of individual users"
- I disagree. This method / technique itself doesn't prevent tracking of
individual users -- what it does (as far as I understand) is allow users to
cancel / supersede / etc postings without being tracked if they choose to use
this.
Section 2.1. Cancel-Lock
This is hard to follow without examples -- please mention that there *are*
examples further in the doc; they are helpful, but only if you know they exist
:-)
"Comments in CFWS can cause interoperability problems" -- please expand CFWS
(perhaps a link to RFC 5322 Section 3.2.2 ?)
Section 3. Use
"This secret strings can" s/This/These (plural)
"An injecting agent acts representitive " - perhaps "acting as representative"
or "acts as the". Also, representitive is misspelled I think (also in S3.1)
"Other agents MUST NOT add this header field to articles or proto- articles
that they process." -- OK, but what if they do? What if the injecting agent /
moderator *doesn't* do add this, but someone else does? Can they then cancel
the posting when they otherwise wouldn't be able to? (As I said, I have no idea
how new normally works, just wondering if allows an external party to escalate
privileges).
Section 5.1:
"Example data for creation of a <c-lock> element with HMAC-SHA256 and empty
string as <uid> (as suggested in Section 4 for posting agents):
Message-ID: <12345@mid.example>"
Is the message-ID strongly tied to the article? E.g can an attacker somehow
attach a message ID (from A) to a different body / article (from B), and then
when A gets cancelled, use this to also cancel B? Just like above, I really
have no idea how Message-IDs are generated / used, so a simple "No, that's
stupid!" is fine :-))
Just like above, mentioning that the examples exist would be helpful higher up
in the document.
Substantive:
-1.2:
Who does this section address? Do you expect it to stay in the final RFC text?
Do you expect readers to do something about it?
-2.1 "If <scheme> is not supported by an implementation, the corresponding
<c-lock> element MUST be skipped and potential following <c-lock>
elements MUST NOT be ignored."
I'm not sure I understand the intent. Only the first may be skipped? What if
following elements also do not support the scheme? (repeats in 2.2)
-7: I'm surprised there's not a stronger recommendation to combine this with a
signature-bases authentication system. It seems like a cancel or supersedes
article should have at least the same level of protection as the original
article.
Editorial:
-1, first paragraph: "... agent that processed the original article has required
to withdraw..."
s/required/requested
-1.1, first sentence: "Any term not defined in this document has the same
meaning as it does
in [RFC5536] or [RFC5537]."
That seems unlikely to be true in any formal sense. Please consider enumerating
the terms that are imported from those RFCs. Or failing that, say something to
the effect of "The terminology from RFCs 5536 and 5537 are incorporated as
defined in those documents."
-3, third bullet: "An injecting agent acts representitive for posting agents
without
support for the autentication system described in this document."
Should this day "acts as a representative" or "acts on behalf of"? (Pattern
occurs several times throughout.)
-3.3: "A Cancel-Key header field MAY be added to a proto-article containing
a Control or Supersedes header field by the poster or posting agent
which will include one or more <c-key> elements. "
This is hard to parse. Please consider active voice.
-4, last paragraph: Please include a reference for OpenSSL
Thanks Paul for the gen-art review! My understanding is that this final change will be requested with an RFC editor note and as such the document can move forward. Not sure if the rules for the new registry must be defined that extensively in this document as they seem to be inline with the usual procedures as defined in RFC8126. However, I guess that's not a problem. Nit: Maybe make this one explicitly normative: OLD "The hash algorithm "sha256" is mandatory to implement." NEW "The hash algorithm "sha256" is REQUIRED to implement."
The GenArt ABNF issue was resolved by posting in erratum on RFC 5536. A small
tweak to the ABNF in this document is needed to match. I suggest the following
RFC Editor Note:
Replace the first 3 paragraphs at the beginning of Section 2:
OLD:
This section describes the formal syntax of the new header fields
using ABNF [RFC5234]. It extends the syntax in Section 3 of
[RFC5536] and non-terminals not defined in this document are defined
there. The [RFC5536] ABNF should be imported first before attempting
to validate these rules.
The new header fields Cancel-Lock and Cancel-Key are defined by this
document, they follow the rules described in [RFC5536] Section 2.2:
fields =/ *( cancel-lock / cancel-key )
NEW:
This section describes the formal syntax of the new header fields
using ABNF [RFC5234]. It extends the syntax in Section 3 of
[RFC5536] and non-terminals not defined in this document are defined
there.
The new header fields Cancel-Lock and Cancel-Key are defined by this
document, extended the list of article header fields defined in in [RFC5536].
The proper use of HMAC as a KDF is to have the secret value be used as the key and the public value used as the value, not the other way around. Even then, it would be better to use HKDF.
Line 225
secret strings can later be used to authenticate a cancel or
supersede request.
This document would be easier to read if this section was earlier up. I had to
kind of infer that you were sending hashes and then using preimages to cancel.
Line 235
o An injecting agent acts representitive for posting agents without
support for the autentication system described in this document.
This is ungrammatical.
Line 236
o An injecting agent acts representitive for posting agents without
support for the autentication system described in this document.
Nit: authentication.
Line 239
o A news administrator wants the ability to cancel articles that
were injected by its system (because they e.g. violate its abuse
policy).
Nit: "e.g." has a trailing comma and also needs a real phrase afterwards as in
"e.g., they violate"
Line 252
If an injecting agent (or moderator) wants to act representitive for
a posting agent without support for the authentication system
See above.
Line 358
K = HMAC(uid+mid, sec)
IMPORTANT: The proper use of HMAC as a PRF is to have the secret value be used
as the key and the public value used as the value, not the other way around.
Line 380
In general every agent must not use the same secret <sec> if multiple
<c-lock> elements are added.
Why don't you instead generate this as:
HMAC(sec, uid || mid || scheme).
Line 384
size of the hash function that is used by HMAC (256 bit / 32 octets
for SHA256) and must be a random value.
This should state "cryptographically random" and cite RFC 4086.
Also, I don't understand the requirement to have a minimum length of the size
of the hash. That's not an HMAC requirement and doesn't make sense if you're
not coupling it to the shash you are using.
Line 647
recommendations remain in the document, or does an RFC exist to refer
to with regards to security recommendations? ]]
I don't see where these values would come from. The size should be orthogonal
to the hash function, and if you did want to match it, should be the same size.
also, you need to cite RFC 4086 here too.
Thanks for a very easy to read and understand document. I have a small number of questions/comments. Section 1.2 gives instructions for representations of names that cannot be accurately displayed with the ASCII character set. Who is the target audience here? If these are intended as instructions for the RFC editor, I note that the current policy is: "no additional non-ASCII documents... will be published until the new format tools are in production." If these are intended as notes to the reader, they're fine (although I might suggest phrasing it as a note for the reader in that case). Section 2 contains the following text: "Because the hash algorithm for <scheme> cannot be negotiated, unnecessary proliferation of hash algorithms should be avoided." Section 8.1, however, defines a first-come-first-served registration policy for these schemes. In light of the observation made in section 2, can you explain why this policy was chosen? Section 3.5 has the following instructions for Cancel-Key validators: To process the authentication, the received article must contain a Cancel-Key header field and the original article a Cancel-Lock header field. If this is not the case, the authentication is not possible (failed). A literal reading of this is that: if I get a cancellation with a "Cancel-Key" in it, but the corresponding article has no "Cancel-Lock," then authentication fails and the article is *not* canceled. This seems to have some unfortunate failure modes when injectors transition from not using this mechanism to using it: since the generation of the key K is performed statelessly, the injector will not know whether an article originally contained a "Cancel-Lock," and will therefore insert a "Cancel-Key" into the cancelling article. If the original article was injected before the cancel lock mechanism was activated, this would then cause the cancellation to fail. Is that the intention? Finally, it may be worth including some information about how rotation of the secret used to generate the various keys K might be achieved.
draft-ietf-bier-architecture
[ After response from Alia I'm clearing my discuss. I still somewhat feel that an Architecture document which discusses an experimental protocol / idea doesn't need to be Experimental itself, but a: I don't feel it very strongly / could be wrong, and b: her "I did discuss with the BIER WG that it is possible to do a status update to move a document from Experimental to Proposed Standard without needing to update the RFC." makes me happy. I'm copying my original discuss comment below for hysterical raisins. ] Notes: Section 1: "If the packet also needs to be sent to a BFER whose BFR-id is 257, the BFIR would have to create a second copy of the packet, and the BIER encapsulation would specify an SI of 1, and a BitString with bit 1 set and all the other bits clear." - while reading this it seemed to me that it would be much simpler to do away with the SI completely and just make the BitString N bits longer (instead of having e.g a one octet SI and 2 octet BitString, concatenate this and have a 3 octet BitString). It was only when I got down to Section 3 that I discovered that this is (kinda) discussed, and that each SI can have a different BitString length. I'd suggest adding a refernce (like: "and a BitString with bit 1 set and all the other bits clear (see Section 3 for more details)." Section 4.1. The Routing Underlay: "Alternatively, one could deploy a routing underlay that creates a multicast-specific tree of some sort, perhaps a Steiner tree." A reference for Steiner trees would be nice -- best I could find was probably the WA page at: Weisstein, Eric W. "Steiner Tree." From MathWorld--A Wolfram Web Resource. http://mathworld.wolfram.com/SteinerTree.html Please note: I'd pay good money for a router doing Steiner optimizations using the soap and surface tension trick. Nits and notes: 1: " A router that supports BIER is known as a "Bit-Forwarding Router" (BFR)." -- this makes me sad; the BFR acronym was already in use, and had interesting history behind it (Big er... Fast Router) - http://photos.kumari.net/Technology/Networking/i-k4vCdwv/A 2: "MVPN signaling also has several components that depend on the type of "tunneling technology" used to carry multicast data though the network." -- though the network what?! I suspect you meant "through" :-) 3: Section 6.1. Overview "If a BFR receives a BIER-encapsulated packet whose sub-domain, SI and BitString identify that BFR itself, ..." -- identifies. O: "When BIER on a BFER is to pass a packet to the multicast flow overlay, it of course decapsulates..." P: "When BIER on a BFER is to pass a packet to the multicast flow overlay, it, of course decapsulates" C: Missing a comma. I suspect: "When BIER on a BFER is to pass a packet to the multicast flow overlay, it decapsulates..." would be even better. Section 6.9. When Some Nodes do not Support BIER "In this section, we assume that the routing underlay is an SPF-based IGP that computes a shortest path tree from each node to all other nodes in the domain." C: I *think* that this should actually be "the shortest path", but I'm not sure; everything talks about e.g Dijkstra's algorithm finding the shortest path, but what if there are multiple equal cost paths? But, this is a singular tree, but may not be unique, so any SP tree will... erk... Good this this is a nit and I can move on :-) Section 6.10.3. Transitioning from One BitStringLength to Another Typo: Dispostion -> Disposition ------ ORIGINAL DISCUSS TEXT ---- I agree with Ben, but feel more strongly than him - why is this Experimental? Where is the experiment / how do you determine if it is successful? The shepherd writeup says: "(1) Experimental, as per charter. The document title page header indicates experimental. ", but this doesn't really answer the question; the charter says: "BIER is initially chartered to do experimental work on this new multicast forwarding mechanism as follows: 1) BIER architecture: The WG will publish an architecture, based upon draft-wijnands-bier-architecture-04...." I really think that this document should be Informational or PS, or something. I can understand the *work* to be experimental in nature, but the document *itself* seems like it shouldn't be - it doesn't (really) explain how to implement. I'm making this a DISCUSS, but am more than happy to clear if the chairs / AD says that the've considered this and Experimental really is best.
I agree with other comments that the architecture document should describe the experiment.
Update: While it is now clearer why this doc is not informational, I agree with the gen-art review (Thanks Dan!) that is could be made even clearer what the experiment is/why this is experimental and not PS. Old ballot text: I also initially expected that this document should be informational because it specifies an architecture, however, while reading I realized that is rather specifies abstract mechanisms and a data model. So it's basically an abstract protocol spec without defining the on the wire format. Maybe it would be helpful to describe the content of this document this way, rather than speaking of an architecture. However, I guess the word architecture is rather board though. Thanks for a well-written doc; especially the ECMP part is very clear!
Next point moved from DISCUSS to COMMENT after the IESG telechat:
1. I want to come back to the experimental status.
I have seen Alia's reply:
In the BIER Charter, work item 9 describes a document based on deployment
experience that can justify moving the BIER work from Experimental to
Standards Track. When I chartered the WG, it wasn't clear whether it was
merely a good idea or a good idea with enough motivations towards
deployment that it is worth complicating the architecture at the narrow
point of the IP hourglass.
From the writeup, it seems that the experiment is successful already:
The vendors are being quite tight lipped about current implementations.
Operator feedback indicates there are at least two implementations
currently, with others in the works. There are currently five vendors
collaborating on the work in the IETF.
However, I've not been following the specifications development and
implementation to provide a definitive answer.
At the minimum, the document needs to describe what the criteria are for a
successful experiment.
Implementations (RFC7942?)?
two interop implementations?
hardware implementation?
"deployment experience" (to cite the charter text)?
impact analysis?
something else?
The ideal BIER document for this explanation is this architecture doc.
A reference to the charter Item 9 would be a good start.
Examples:
https://tools.ietf.org/html/rfc7360#section-1.3
https://tools.ietf.org/html/rfc7499#section-2
- Each BFR MUST be assigned a single "BFR-Prefix" for each sub-domain
to which it belongs. A BFR's BFR-Prefix MUST be an IP address
(either IPv4 or IPv6) of the BFR. It is RECOMMENDED that the
BFR-prefix be a loopback address of the BFR.
Just one observation. Was thinking, so it's like an (OSPF) routerId, except
that it's called a prefix. Then I understood, reading further. It's not called
a routerId because this address/prefix must be routable
- Was wondering. Is this mechanism only for multicast packets? What about
anycast/unicast? Some multicast packets would take BIER encap, while others
packets would take a different encap From a troubleshooting point of view, does
it make sense (is it even allowed) to send non multicast traffic over BIER.
Just asking for my own understanding ... In this text, If, at some time, the routing underlay is not providing a loop free path between BFIR-A and BFER-B, then BIER encapsulated packets may loop while traveling from BFIR-A to BFER-B. However, such loops will never result in delivery of duplicate packets to BFER-B. I'm assuming that these loops could result in out of order delivery of packets to BFER-B? No document change requested, of course. And either answer is fine.
Not wishing to re-litigate any of the previous discussions (for which I was not available), I have reviewed only the deltas between -07 and -08. I have no objection to the changed and new material.
I'm a bit confused about the experimental status of this document as well, given that the other WG drafts that define protocol extensions to support BIER seem to be headed for the standards track. If what is documented here really is the only experimental part, this seems like the place to document the experiment.
draft-kille-ldap-xmpp-schema
You may notice that the shepherd's writeup says "Proposed Standard". The correct intended status is "Informational". Alexey will update the writeup.
Thanks for addressing the comments from the SecDir review.
Section 4 says "BP 64" where I believe "BCP 64" was intended.
Document created by my co-worker. I am the document shepherd, due to some LDAP and XMPP experise.
status-change-ecn-signaling-with-nonces-to-historic