IESG Narrative Minutes
Narrative Minutes of the IESG Teleconference on 2015-08-20. These are not an official record of the meeting.
Narrative scribe: John Leslie and Susan Hares (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:
Telechat:
Telechat:
Telechat:
2.1.2 Returning items
2.2 Individual submissions
2.2.1 New items
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
Telechat:
Telechat:
3.1.2 Returning items
3.2 Individual submissions via AD
3.2.1 New items
3.2.2 Returning items
3.3 Status changes
3.3.1 New items
3.3.2 Returning items
3.4 IRTF and Independent Submission stream documents
3.4.1 New items
Telechat:
Telechat:
3.4.2 Returning items
Telechat:
1053 EDT no break
4 Working Group Actions
4.1 WG Creation
4.1.1 Proposed for IETF Review
4.1.2 Proposed for Approval
4.2 WG Rechartering
4.2.1 Under evaluation for IETF Review
Telechat::
4.2.2 Proposed for Approval
5. IAB News We can use
6. Management Issues
Telechat::
Telechat::
Telechat::
Telechat::
Telechat::
7. Working Group News
Cindy: doodle for BoF call, if you haven't; I will be on Pacific time next week
1132 EDT Adjourned
(at 2015-08-20 06:00:02 PDT)
draft-ietf-trill-oam-mib
- Grepping for "MAX-ACCESS *read-create" gives me 28 hits. The security considerations section describes 5 of those that I can see. Are you saying that you did check but all of the others are read-create are not in fact sensitive? - The security considerations here might note two additional things. First, access to the read-only date exposes the network topology so might be considered more sensitive than other MIBs. And second, if one can set an IP address to which reports are sent say in the event of some kind of packet storm, then that could maybe be used to DoS that IP address. I'm not sure either is worth a mention, but just wanted to check in case they might be.
A few nits: -- section 3: s/is intended to provide/provides ; (Unless you are concerned that it did not succeed? Please expand OAM on first mention. -- 5.3.1: s/fault alarm/fault alarms -- 6 (title) s/module/modules -- 6, first paragraph, "relevant to TRILL OAM MIB" missing article -- 6.1, first paragraph: Is there a reason to capitalize "Augments" and "Augmenting"? --6.1, 2nd paragraph: I have trouble parsing this paragraph. Do you mean some implementations do not support Link Trace Messages? All implementations? The TRILL standard? I suggest the latter part of the sentence be “statistics for these messages should have default values as per…"
Thanks for the updated Security Considerations in the SecDir review, that update will address my concerns. https://www.ietf.org/mail-archive/web/secdir/current/msg05934.html
Weird that this document uses the old template, with Status of this Memo as the first section. I would suggest doing a pass of this whole document to clean up the English before it goes to the RFC Editor, as there are enough places where the grammar is ambiguous that it would be better not to have the RFC Editor try to interpret them all. Some examples of issues that seem to occur throughout the document: Missing articles (e.g. Sec 5.3, "trilloamNotifications are sent to management entity") Inconsistent capitalization (e.g. in the definition of trillOamMepTxLbmReplyModeOob, "True Indicates that Reply of Lbm") Subject-verb agreement problems (e.g., in the definition of trillOamMepTxMtvmMessages, "Rbridge retransmit the Multi Destination message") Ambiguous text (e.g., in the definition of trillOamMepTxPtmMessages, "Once Destination or Hop count reaches it's treated as single Counter increment of this object")
Melinda Shore did the opsdir review. would like to see the question of the
security considerations setion addressed.
----
I have reviewed this document as part of the Operational
directorate's ongoing effort to review all IETF documents
being processed by the IESG. These comments were written
with the intent of improving the operational aspects of the
IETF drafts. Comments that are not addressed in last call
may be included in AD reviews during the IESG review.
Document editors and WG chairs should treat these comments
just like any other last call comments.
Summary: The document is in good basic shape, with some
weaknesses in the security considerations. I'd like to
see those remedied but I'm not sure they're serious enough
to recommend blocking publication.
This document specifies a MIB for TRILL.
This document has been received MIB doctor review and
issues raised during that review have been been resolved.
The security considerations section is weak, but not
fatally so. The draft identifies exposing MAC addresses as a
potential privacy issue but does not identify other security
considerations specific to this particular MIB module, which
is unfortunate given the inclusion of writable objects. More
specificity about which security mechanisms to use might help
avoid interoperability problems. Also, in this climate it may
be useful to separate out the privacy issues into a "Privacy
Considerations" subsection.
The nits checker found:
. two instances of non-RFC5735-compliant IPv4 addresses
. a missing reference to CFM. This one is wrong - CFM
is identified and a reference provided in the Introduction
(section 1)
Melinda
draft-ietf-trill-aa-multi-attach
Just one question. In this text: 5.3.2. No Echo (Split Horizon) When a multi-destination frame originated from an LAALP is ingressed by an RBridge of an AAE group, distributed to the TRILL network and then received by another RBridge in the same AAE group, it is important that this RBridge does not egress this frame back to this LAALP. Otherwise, it will cause a forwarding loop (echo). The well known 'split horizon' technique is used to eliminate the echo issue. Is there a canonical (or semi-canonical) reference for split horizon that you could provide here? A pointer to Appendix A would help, but that's more of a description of how to do split horizon than a description of what split horizon is. I see that Ben also asked for this ...
- abstract: "Thus, remote edge RBridges are required to keep multiple locations of one MAC address in one Data Label." I find that very hard to read and don't understand what it's telling me. Even if these terms are terms-of-art for trill, it'd be worth being less opaque in the abstract. I have the same problem with the intro. I think if you tried to be specific about whose MAC address you mean (a host attached to RBridges in the AAE) and also explained (or avoided) the term "Data Label" here that'd help. - 5.1: for how long is a remote RBridge "required to adhere"? (Sorry if that's clear in 4.1, in which case I missed it.) - 5.3.2: "well-known split horizon technique" just screams for a reference. Please add one, which is presumably easy to do as this is well-known:-) - security considerations: I'm surprised there's nothing new here. Did someone do the analysis to check? (Sorry for doubting you but security considerations sections like this that only consist of references are often an indicator that nobody did take a real look;-) One possible example (not sure if it works): if I can fake an ESADI message then I could pretend to be the RBridge in the AAE that has least cost and so lots of traffic would be sent to me, instead of the real RBridges in the AAE. Compared to the situation without this specification, that might mean a more effective attack. Now I'm not really sure if that's true or not (I'm sure you'll tell me) but my question is whether or not those kinds of thing were considered already.
A few minor comments (no show stoppers): -- section 4.1, first paragraph: "However, alternative implementations MAY be used to produce the same expected behavior." Does this talk about same “behavior” of an RBridge (as in the observable one-the-wire bits are identical) or same “results” for the system (as in the receiving RBridge does not flip-flop)? If the former, it probably should not be normative. -- section 5.3.2: This section defines a sub-tlv, and related behavior. That probably doesn’t belong in the design goals analysis section. (I predict that many readers will skip section 5 entirely). Please consider moving this under section 4. Also, can you cite something for the "well-known 'split horizon' technique"? -- section 7: This draft defines new data elements. It seem likely that nothing in those new elements add security considerations beyond those in the cited specs. But it would be helpful to explicitly state that. -- 8.3: Are you for specific flag values (16 and 4 respectively), rather than allowing IANA to assign the values as needed? Also, it seems odd to recreate the entire flag registries in a spec that merely adds new flags. The registry will change over time; this runs the risk of a reader assuming the contents listed here are current at any point in the future. (But I see that other TRILL specs have done the same.) Editorial Comments and Nits: -- Abstract: Please expand TRILL on first mention in the abstract. -- section 1, first paragraph: Please expand TRILL on first mention in the body, too. -- 4.1, first paragraph: "... in MAC learned from the TRILL...": Missing article s/It's/It is "A promising way..." : “promising” in this context seems to imply the option is likely, but not certain to work. Is that the intent? s/So the receiving edge.../The receiving edge... -- 4.1, 2nd paragraph: Sentence 1 is a little confusing. I assume the intent is to say that this draft allocates the reserved flags, and the flags are used to advertise the data labels? As it is, it sounds like the act of allocation advertises the data labels. In sentence two, should "this flag" be "these flags"? -- 4.1, paragraph 3: "...it MUST be advertised..." I assume this means that the originating RBridge MUST advertise it? (Please consider active voice for 2119 requirements. ) -- 5: Consider “This section explores how this specification meets the major design goals of AAE”
I was also surprised there were no additions for this capability to the security considerations and will follow along to responses on Stephen's question on the same topic. Thanks.
I've already had an exchange with an author about these comments, and he's resolving them very much to my satisfaction. Thanks! -- Section 4.1 -- It's RECOMMENDED that the receiving edge RBridge disable the data plane MAC learning from TRILL Data packet decapsulation within those advertised Data Labels for the originating RBridge unless the receiving RBridge also supports Option A. However, alternative implementations MAY be used to produce the same expected behavior. A minor point, because I think people will properly understand this, but the "SHOULD do X but MAY do Y" construction is a misuse of 2119 language -- the MAY contradicts the SHOULD, because "MAY" says that doing Y is entirely optional. In this case, I think the best fix is to remove the 2119 language from the second part, making the last sentence, "Alternative implementations that produce the same expected behavior are acceptable," which leaves the initial RECOMMENDED in force. -- Section 5.3.1 -- If the output of the selection function points to the port attached to the receiving RBridge itself (i.e., the packet should be egressed out of this node), it MUST egress this packet for that AAE group. What is the antecedent to "it"? It looks like it's "the output of the selection function", but I think it's supposed to refer to "the receiving RBridge"; is that right? If so, I suggest making that clear: NEW If the output of the selection function points to the port attached to the receiving RBridge itself (i.e., the packet should be egressed out of this node), the receiving RBridge MUST egress this packet for that AAE group. END (It is output or not as specified in [RFC6325] updated by [RFC7172] for ports that lead to non-AAE links.) I can't parse this, and have no idea what it means; can you please rephrase? -- Section 5.3.2 -- When a multi-destination frame originated from an LAALP is ingressed by an RBridge of an AAE group, distributed to the TRILL network and then received by another RBridge in the same AAE group, it is important that this RBridge does not egress this frame back to this LAALP. In the last phrase, what is "this RBridge"? There are two RBridges mentioned. I think you mean "it is important that the second RBridge does not egress the frame back to the originating LAALP." Customer may need hosts within these overlapped VLANs to communicate with each other. I tried a few ways to interpret this before settling on the one I think you mean. First, it needs to say either "Customers" or "A customer", and it's not clear which. Second, it's not clear whether you want customers or hosts to communicate. I think this is what you mean; is it?: NEW A customer may require that hosts within these overlapped VLANs communicate with each other. END -- Section 5.5 -- In doing this, the forwarding paths need not be limited to the least cost Equal Cost Multiple Paths from the ingress RBridge to the AAE RBridges. This reads confusingly, because it doesn't make sense to have a least cost entry from among ECMPs. I gather that what you mean to say is that the ECMP comprises a set of equal-cost paths, and that set represents the least cost choice. Let's see if we can find a way to word that which doesn't sound confusing. Is it even necessary to mention ECMPs here, when the term isn't used elsewhere in the document? Might this work just as well?: NEW In doing this, the forwarding paths need not be limited to the least cost path selection from the ingress RBridge to the AAE RBridges. END -- Section 5.6 -- In the first sentence, "option A" should have "Option" capitalized, to be consistent with other uses of "Option A". Similarly for "option B" in the second paragraph. -- Section 8.2 -- I'm not making this a DISCUSS, but... it would be useful to have some guidance for the designated expert. What should she be considering in deciding whether to approve a registration request? I presume the expert review is to make sure the 62 remaining bits aren't expended frivolously, so what guidance can you give about when it's appropriate to say "no"? -- Section 8.3 -- I strongly suggest that you not duplicate the whole table here, but only show the entries you're adding. And the section title should probably have a hyphen in "Active-Active". Also, the registry names aren't right; they're called "Interested VLANs Flag Bits" and "Interested Labels Flag Bits": http://www.iana.org/assignments/trill-parameters#interested-labels-flags
draft-ietf-ospf-prefix-link-attr
More a comment for IESG discussion, this draft has six authors (exceeds five author limit). I didn't see any notes in the shepherd writeup to support the need to exceed the limit (my former AD required a strong argument for exceeding). What guidelines are we following? I have many drafts coming along which exceed the limit and wondering what to do.
- The opaque ID field descriptions in sections 2 and 3 read a little oddly to me. What happens if someone decides to use up ID=0? Does that mean they can't overwrite that value until much later maybe? And what if a whole bunch of routers choose the same value (because it's configured or hard-coded)? I think you need a bit more text on that. And with only 24 bits the probability of a collision if you just pick randomly isn't that low, so I'm not sure if random selection is a good plan here either. (How often will a new one of these be seen?) - Do these opaque values get forwarded widely? If so, then I guess they may provide a covert channel. I didn't see that mentioned in the security considerations of RFC5250. Is it mentioned elsewhere? If not, is it worth a mention here? (Probably not, but thought I'd ask.) - Thanks for section 5. Nice to see. (Makes me wonder what those implementations do with the opaque ID though:-)
This is a good document, but I have some comments (and nits) that I would really like to see addressed before publication. I don't think my comments raise to the level of a DISCUSS, but I am specially interested in the actions when errors are detected. 1. Sections 2 and 3. a. RFC5250 used the name Opaque ID instead of Instance. Please be consistent. If there’s a really good reason to not use the “official” name, please at least write in the description of Instance that rfc5250 calls it Opaque ID. b. “…the attributes from the Opaque LSA with the lowest Instance will be used.” This sounds to me like a good place to be a little bit more prescriptive and s/will/MUST 2. Section 2.1. (OSPFv2 Extended Prefix TLV) a. For the Route Type, are those the only allowed values? What happens if something else is used? b. Flags - What are the defined flags used for? Since (according to Section 5) they are not supported in all implementations then I’m assuming there’s a specific application in mind. [I know there are other ID’s in progress that use the TLVs defined here. Is the use of these bits general to those applications?] - How should the rest of the flags be assigned? The IANA section says nothing about that. c. "Address Prefix The prefix itself encoded as a 32-bit value.” It is variable, not fixed. I know that only IPv4 is currently supported, but as explained in the AF section, there may be future extensions. 3. Section 3.1. (OSPFv2 Extended Link TLV) What should happen if an unknown/incorrect Link-Type/Link-ID/Link Data value is received? 4. Section 6. (Security Considerations) a. I think you should also point the readers at the considerations in rfc5250. b. “…implementations must assure that malformed TLV and Sub-TLV permutations do not result in errors that cause hard OSPF failures.” What does that mean? That the software should be resilient? Or are you pointing at just ignoring the information if there is a malformed TLV/sub-TLV (that is somehow salvageable)? It would be vey nice is this draft set the example by specifying what to do in some cases (maybe not malformed, but incorrect/unknown as mentioned above). 5. Section 7. (IANA Considerations) Is there a significant reason why in all cases the assignment policy for the 33024-65535 range is not being defined upfront? Nits: 1. In Sections 2 and 3 s/differential/differentiate 2. In Section 2. (OSPFv2 Extended Prefix Opaque LSA), the figure that shows the TLV format seems to show a Value field of only 32 bits. The description (below the figure), which looks like an exact copy from rfc3630, describes the field correctly. It would be nice to either copy over the whole text from rfc3630 (including the figure that shows that the Value may be longer) or just leave out that text completely (which is my preference). The text saying that the TLV format is the same as in rfc3630 is enough. - In Section 3 you write: "The format of the TLVs within the body of the OSPFv2 Extended Link Opaque LSA is the same as described in Section 2.” One more level of indirection.. 3. 2.1. (OSPFv2 Extended Prefix TLV) a. The description of “Flags” is misaligned (it looks like a sub-paragraph of AF). b. s/originated by the different/originated by different
I concur with Kathleen's DISCUSS and Alvaro's comment about the security considerations. Other comments: -- 2.1, definition of N-Flag There are a couple of occurrences of "NOT" in caps that are not combined with other 2119 keywords. I assume those are not intentional? -- 2.1, 4th paragraph from end, last sentence (also occurs in 3.1): The 2119 MAY here doesn’t seem helpful, since this is internal to a router and does not impact seem interoperability. I suggest it be restated without 2119 language, unless you want to make it a SHOULD or stronger. (I am not a stickler that 2119 keywords never be used for things that are not observable by a peer, but MAYs seem especially useless in that context. I did not object to the SHOULD in the prior paragraph, since that might have operational value.)
Thanks for your work on this draft. I have questions along the lines that Alvaro raised on the last sentence of the Security Considerations section, but in context of security, this is something that should be discussed. "Additionally, implementations must assure that malformed TLV and Sub-TLV permutations do not result in errors that cause hard OSPF failures." It would be very helpful to expand upon this statement. Are there exploits that could result as well? Should this instead be scoped in terms of what is valid so that the appropriate actions occur consistently when an invalid or malformed TLV or sub-TLV are received? I would think the answer to the last question would clarify this enough for this security consideration and if that's not possible, can you explain what I'm missing? Thank you.
Some minor comments, just some clarifications... and a question about the registries. -- Section 2 -- There is no explanation of the "length" field in the OSPFv2 Extended Prefix Opaque LSA. I guess it's the total size, in bytes, of all the TLV data that follows, including any alignment bytes. But you should make that clear. -- Section 3 -- The same comment as for Section 2 applies here for the OSPFv2 Extended Link Opaque LSA. -- Section 7.1 -- Types in the range 33024-65535 are not to be assigned at this time. Before any assignments can be made in the 33024-65535 range, there MUST be an IETF specification that specifies IANA Considerations that covers the range being assigned. A question here (I'm not hoping for any particular answer, just asking the question): When you say "an IETF specification", I take that to mean an RFC in the IETF stream, which can be Standards Track *or* Informational *or* Experimental. Is that what you want? The same question applies to the registries in the subsequent sections (7.2, 7.3, 7.4).
Ron Bonica did the opsdir review.
draft-ietf-avtext-rtp-stream-pause
This draft was really easy for me to read (with some background in RTP/RTCP,
but I'm no expert on the topic). Thank you for the work on it - the results
show.
I have some questions, but nothing is a show-stopper.
In this text:
3.3. RTP Mixer to Media Sender in Point-to-Multipoint
In this use case there are several receivers of a stream and special
care must be taken as not to pause a stream that is still wanted by
some receivers.
I'm assuming that the Mixer is taking special care, but this is passive enough
that I'm filling in blanks. If you like passive voice, perhaps something like
In this use case there are several receivers of a stream and special
care must be taken by the Mixer so as not to pause a stream that is
^^^^^^^^^^^^^^^
still wanted by some receivers.
would be easier to parse.
If you can do active voice, perhaps
In this use case there are several receivers of a stream and the
Mixer must take special care so as not to pause a stream that is still
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
wanted by some receivers.
In this text:
8. Message Details
Any references to PAUSE, PAUSED, RESUME and REFUSED in this section
SHALL be taken to apply to the extent possible also when TMMBR/TMMBN
are used (Section 5.6) for this functionality. TMMBR/TMMBN MAY be
^^^
used instead of the messages defined in this specification when the
effective topology is point-to-point. If either sender or receiver
learns that the topology is not point-to-point, TMMBR/TMMBN MUST NOT
be used for pause/resume functionality. If the messages defined in
this specification are supported in addition to TMMBR/TMMBN by all
involved parties, pause/resume signaling MUST use messages from this
specification. If the topology is not point-to-point and the
messages defined in this specification are not supported, pause/
resume functionality with TMMBR/TMMBN MUST NOT be used.
All of this makes sense to me, except that I'm not understanding why
TMMBR/TMMBN is a MAY. There's a lot of text that says you really need to use
the messages from this specification in this case, and in that case, and ...
but here, you MAY do something else.
I understand that TMMBR/TMMBN works in a point-to-point topology, but is there
a reason to prefer TMMBR/TMMBN in that topology? If so, it would probably be
good to explain why.
And as I read futher, I see this, in section 9:
Note: When TMMBR 0 / TMMBN 0 are used to implement pause and
resume functionality (with the restrictions described in this
specification), signaling rtcp-fb attribute with ccm tmmbr
parameter is sufficient and no further signaling is necessary.
There is however no guarantee that TMMBR/TMMBN implementations
^^^^^^^^^^^^
pre-dating this specification work exactly as described here when
used with a bitrate value of 0.
and that really makes me wonder why this specification is also describing
TMMBR/TMMBN. I'm sure there's a good reason, but can you understand my
confusion?
Finally, I see this, in section 9.1,
If both "pause" and "tmmbr" are present in the offer, both MAY be
included also in the answer, in which case TMMBR/TMMBN MUST NOT be
used for pause/resume purposes (with a bitrate value of 0), to avoid
signaling ambiguity.
and in section 9.2,
If both "pause" and "tmmbr" are present in the SDP, TMMBR/TMMBN MUST
NOT be used for pause/resume purposes (with a bitrate value of 0), to
avoid signaling ambiguity.
I'm now wondering if the description of TMMBR/TMMBN in this specification just
for interworking with older implementations that don't support PAUSE/RESUME but
figured out how to get a similar effect with TMMBR/TMMBN?
I'm guessing, of course :-)
In this text:
8.5. Transmission Rules
o PAUSE SHOULD use Early or Immediate timing, except for
retransmissions that SHOULD use Regular timing.
^ I understand this one.
o The first transmission of PAUSED for each (non-wrapped) PauseID
SHOULD be sent with Immediate or Early timing, while subsequent
PAUSED for that PauseID SHOULD use Regular timing. Unsolicited
PAUSED (sent when entering Local Paused State (Section 6.4))
SHOULD always use Immediate or Early timing, until PAUSED for that
PauseID is considered delivered at least once to all receivers of
the paused RTP stream, after which it SHOULD use Regular timing.
^ I'm wondering why these are SHOULDs. Are they MUSTs except that some
implementations don't do it, or recommendations but nothing breaks if you don't
do them, or something else?
o RESUME SHOULD always use Immediate or Early timing.
^ I wonder why this is SHOULD. Is there any guidance you can provide about why
RESUME would use Regular timing?
o The first transmission of REFUSED for each (non-wrapped) PauseID
SHOULD be sent with Immediate or Early timing, while subsequent
REFUSED for that PauseID SHOULD use Regular timing.
^ I am, of course, wondering about the corresponding SHOULDs for REFUSED.
In this text:
9. Signaling
When signaling a config value other than 1, an implementation MUST
ignore non-supported messages on reception, and MAY omit sending non-
supported messages.
is this saying that an implementation might send non-supported messages? I'm
confused here.
- 58 pages! There is quite a bit of repetition here but too late to change now. - I see there are 2 IPR declarations, both with possible royalty/fee and neither that I can see actually specifying what patent (or other property) is involved despite both declarations being some years old. (And there was me thinking remote controls were almost older than me, but I guess what do I know and the USPTO must always be right;-) Anyway, can someone point me at where the working group said they were ok with this situation? (The shepherd write up says that happened so I hope it's not hard to get that pointer.) - Section 7: in a multiparty call, say participant#1 hits pause with PauseID = 0x0001, and stuff is resumed some time later, is participant#2 supposed to use a PauseID of 0x0002 subsequently? In other words does the SHALL there apply to everyone on the call or just to the participant who sent out the last PAUSE message? If the former, does that create a race condition? Or maybe that's a harmless race? I guess you could reduce the probability of a race by recommending that PauseID be randomly selected between last-PauseID-seen and last-PauseID-seen+(2^14) or something like that? (And apologies if all this is obvious to someone expert in RTP, I am not that person:-)
The SecDir review brought up a couple of attack types and at least the first should be mentioned in the security considerations section, replay protection. For the second, does it apply? https://www.ietf.org/mail-archive/web/secdir/current/msg05921.html Thank you.
I have a meta-question about why this "updates" 5104. It appears to be an extension to 5104, using normal extension mechanisms -- someone implementing 5104 and not intending to implement this would have no reason to look at this document, as far as I can tell. I don't see anything that describes a *change* to 5104 (though perhaps I've missed it). What's the reasoning behind specifying "updates"?
draft-ietf-ippm-2680-bis
Just reviewing the changes: 2.8.1: s/in future/future
For the most part, this draft looks good, but the security considerations haven't been updated from the previous release. An important consideration for traffic measurement is that it could be used for reconnaissance activity. By colecting results (passively or actively) of measurement data, you learn more about the network and that can be used in subsequent attacks. Can you add this consideration into the text? Thank you!
Nice to see us moving documents to Internet Standard when it's appropriate.
No issues from my perspective given I only reviewed the changes (diff is a wonderful thing) between this draft and RFC 2680.
Same comment I had on the security considerations section in draft-ietf-ippm-2679-bis. I don't think it's quite accurate to say "there can be no release of existing user data."
draft-ietf-ippm-2679-bis
I support Alissa's DISCUSS. The newly added comment in 3.6 about transport layer encryption is egregious and should be deleted or else some justification should be offered. I would have hoped for a fuller exposition of the positive and negative impacts of encryption, or none. - the secdir review [1] notes some nits. [1] https://www.ietf.org/mail-archive/web/secdir/current/msg05920.html
(reviewing only the changes) -- 3.6: I concur with Alissas's DISCUSS about the added sentence about the impacts of transport encryption. -- 5.4: Why not just remove the deprecated statistic? Nits: -- section 1: If there's another update, I suggest moving this to an appendix and not leave it up to the RFC editor to decide. Also, do you expect the RFC editor to remove the opening note? If so, I recommend saying so explicitly. s/differencer/differences
I support Alissa's discuss. Alissa's comment reads as being more focused on privacy considerations and this point should be expanded to consider operational security considerations that have been around for a long time, but were not in the original text of this RFC. Collecting measurement data or using measurement data for reconnaissance to later attack systems is quite common. Access to this data or the ability to use measurement techniques to do reconnaissance activity should be guarded agist or at least noted as a security consideration. When you look at text to address her comment, please expand it to include this operational security consideration as it is a very real and present threat. This is pretty much the same as my discuss on the other IPPM draft. Thank you.
Nice to see us moving documents to Internet Standard when it's appropriate.
No issues from my perspective given I only reviewed the changes (diff is a wonderful thing) between this draft and RFC 2679.
I am confused about the last sentence in this methodology step in Section 3.6:
"+ At the Src host, select Src and Dst IP addresses, and form a test
packet of Type-P with these addresses. Any 'padding' portion of the
packet needed only to make the test packet a given size should be
filled with randomized bits to avoid a situation in which the
measured delay is lower than it would otherwise be due to compression
techniques along the path. Note that use of transport layer
encryption will counteract the deployment of network-based analysis
and may reduce the adoption of network-based payload optimizations
like compression."
I don't understand what is implied about the relationship between transport
layer encryption and one-way delay measurements. I thought the metric defined
in this document was generally used for end-to-end measurement of delay, so I
don't understand what "network-based analysis" has to do with this methodology
step. Is the implication that if the measurement packet is encrypted at the
transport layer that delay will change? If that is true, isn't the metric
itself agnostic to that consideration -- that is, couldn't that be precisely
what the person doing the measurements wants to measure? I could quibble with
the conclusions of the note itself (e.g., increased transport layer encryption
may change but not necessarily reduce network-based "analysis" of various
sorts), but mainly I do not understand how it relates to the specification of
the metric.
Unfortunately the rationale given in Section 1 ("Added text recognizing the
impending deployment of transport layer encryption in section 3.6") does not
clarify this either. What impending deployment is this referencing?
From Section 6: "The privacy concerns of network measurement are limited by the active measurements described in this memo. Unlike passive measurements, there can be no release of existing user data." I realize this is text from RFC 2679, but I think it would be good to update it to reflect what has been learned since the publication of that document. The mere fact that a host is involved in conducting measurements could well be considered privacy-sensitive in some contexts. And a collection of measurements about a host, even active measurements, could leak information about the host's connectivity/availability/etc. if not appropriately safeguarded. I don't think this changes the protocol requirements for this document, but I do think the text above should note these aspects (perhaps similar to how it's done in <https://tools.ietf.org/html/draft-ietf-lmap-framework-14#section-8.3>). It's not quite correct to say there can be no release of existing user data.
draft-ietf-dime-ovli
Nice job on the Security Considerations! It would be very nice if end-to-end encryption were supported, but I do appreciate the detail level on the risks/security considerations that were included in the draft.
draft-ietf-grow-filtering-threats
- intro 1st sentence confuses me at least. The 2nd paragraph does explain it nicely though when I get to page 3. Maybe try re-word that opener? Or just delete para 1? - Figure 4 is mentioned in 2.2.1, and includes AS65404, but that ASN is not mentioned in the text in that section which is confusing, or is there a typo? I also didn't quite follow the description in 2.2.1 either which may be related or independent;-) - I'm guessing, but didn't check in detail that -07 includes changes from the secdir review [1] (which raised some nits). If so, thanks! [1] https://www.ietf.org/mail-archive/web/secdir/current/msg05853.html
I have a non-blocking comment related to the characterization of the unexpected traffic flows (and a nit). Section 6. (Security Considerations) Throughout the document the unexpected traffic flows were characterized as potential policy violations, not as routing security issues as is done here. I know that the text has gone around the point of malicious intent (or not) before, but I think that if you’re going to mention that it could be a "potential routing security issue”, then you should say something more about it (even if it is the result of non-malicious intent) — or just leave it at policy violations. Nit: The example in Section 2.2.1. (Unexpected traffic flows caused by remotely triggered filtering of more specific prefixes) didn’t look good to me at first..then I re-read the text until I discovered that the other ASes (including 64505) are peering with both 64502 and 64503. Because of how Figure 4 is drawn, it looks like 64505 is only connected to 64502. Maybe centering that AS will avoid confusion.
I think Robert Sparks followup Gen-ART review of version 07 deserves consideration: https://mailarchive.ietf.org/arch/msg/ietf/rG31yTd2kDc8PaTCaoVyZ5ZJDbg
I have no issues with the publication of this document. The following are simply voiced for your consideration... 1. I think the comment in 3.2 about how difficult it is to get routing policies from external entities is undersold. Most organizations won't share that information since it might reveal business arrangements they consider proprietary. I would suggest being explicit in the cause for the difficulty in obtaining such information. 2. Section 4.2.1 seems to be hinting at a UI deficiency in routing platforms in that a route filter installed in the control plane should automatically result in an ACL installed in the forwarding plane. That sounds like an intriguing capability. 3. All of the approaches described in section 4 seem littered with caveats on their effectiveness. Is there any definitive data on the effectiveness of these techniques?
draft-ietf-opsec-ipv6-host-scanning
I echo Barry's "nice document", and would support the changes he suggested.
I did notice what I believe is a repeated "not" in "it is not not only the
lowest-order byte".
In this text:
3.4.1. Remote IPv6 Network Scanners
Many address scanning tools such as nmap [nmap2012] do not even
support sweeping an IPv6 address range.
^
does this mean "sweeping an IPv6 address range in a remote IPv6 network"? I
think that's implicit from the section title, but what nmap supports is clearer
in the corresponding text in the next section:
3.4.2. Local IPv6 Network Scanners
There are a variety of publicly-available local IPv6 network
scanners:
o Current versions of nmap [nmap2012] implement this functionality.
- general: @Fernando: thank you for writing a document that does not recommend turning off IPv6:-) - general: shouldn't you recommend a honeynet approach as another way of spotting scans when there ought be none? That might fit in 3.5 I guess. - intro: what evidence is there that the number of hosts per subnet is likely to stay the same? (And what do you consider an IPv4 subnet here? a /16 is it? Maybe worth saying.) The density point still applies though, but good to not assume things that aren't needed. - 3.1.1 - I would recommend you check with Christian Huitema about Windows10 which has some new features related to MAC addresses. I don't know if there is new IPv6 handling associated with those changes. - 3.4.1 s/patters/patterns/
Just a couple of nits: 1. If this document obsoletes rfc5157, then it can’t really update it, can it? You mention it updates and obsoletes 5157 in the Abstract and Introduction. 2. Introduction. I think you meant: s/[van-Dijk] describes a technique for leveraging DNS reverse mappings for discovering IPv6 nodes./Section 4 describes a technique for leveraging DNS reverse mappings for discovering IPv6 nodes [van-Dijk]
Nice document you have here. Just two really small comments, neither of which
needs any response, and both of which you can ignore if you prefer.
An observation: Three times, you say that something is "obvious", and this can
come across as condescending -- and can be frustrating to a reader for whom it
isn't obvious. I suggest omitting that, so
- In Section 3.1.1.1, change "Firstly, as it should be obvious from the
algorithm described above" to "Firstly, as shown by the algorithm described
above".
- In Section 3.1.3.2, change "For obvious reasons, the search space for
addresses following" to "The search space for addresses following".
- In Section 3.3, change "Obviously, a number of other network reconnaissance
vectors" to "A number of other network reconnaissance vectors".
-- Section 3.1.1.1 --
An observation, for which the response is probably "everyone knows this, so no
change is needed," but please think about it for a fleeting moment:
1. The "Universal" bit (bit 6, from left to right) of the address is
set to 1
Bit 6, starting from 0, or from 1? The answer (which I can see from the
example) is "starting from 0."
Firstly, as it should be obvious from the algorithm described above,
two bytes (bytes 4-5) of the resulting address always have a fixed
value (0xff, 0xfe)
Bytes 4-5, starting from 0 or from 1? The answer (which I can see from the
example) is "starting from 1."
The fact that the origins differ makes me think that it'd be nice if that were
made clear. Please give it a thought, to say that bits are numbered from left
to right starting at 0, and bytes are numbered from left to right starting at 1.
Interesting work, thanks. On the VMWare ESX example given in Sec. 3.1.1.1, the OUI given for automatically-generated MAC addresses (00:05:59) does not seem correct. In the linked documentation, it is listed as 00:0C:29. In the IEEE OUI list, 00:0C:29 is registered to VMWare but 00:05:59 is registered to some other company. In Sec. 3.1.1.3 and 3.1.1.4, I wonder if you might want to re-use the terminology from draft-ietf-6man-ipv6-address-generation-privacy in the section headings, in particular to differentiate "Constant" IIDs from "Stable" IIDs. I think this would be better than using "Privacy-Enhanced" as the term "privacy" is now overloaded when it comes to different types of v6 addresses. I think the tables in 3.1.5 would be a lot more useful if the table captions noted the total number of addresses investigated (N). In Section 3.5, wouldn't using RFC 4941 addresses count as a mitigation as well (first bullet)? Sections 5-13 seem like they belong as subsections of an overarching section about "Other Network Reconnaissance Techniques" or some such. It might also help to provide some indication of how resource-intensive these techniques might be relative to each other. There are other application-specific ways of gathering information about active IP addresses that aren't listed here (the example that comes to mind is an attacker standing up a TURN server) but are probably also more trouble than they're worth for most attackers, which is presumably why they are not included in the list.
conflict-review-cordeiro-experience-mapt
A comment for the authors/ISE: it'd have been nice if this had considered DNS and in particular DNSSEC - I forget if MAP-T impacts on that or not. It also looks a little odd that there's no mail or IM tests in the test set. But overall, good to see people doing these kinds of test.
conflict-review-saarinen-blake2
I'm assuming the description is accurate. Kathleen did send a mail to saag to check and we've seen nobody say there's a problem.
conflict-review-tsou-behave-natx4-log-reduction
By making some kinds of attack easier, (the draft says "the reduced range sizes proposed by the present document increase the attacker's chances"), this could maybe be considered to justify a response of "The IESG has concluded that this document extends an IETF protocol in a way that requires IETF review and should therefore not be published without IETF review and IESG approval." I'm not sure in this case that this is making CGN so much worse that that ought apply, but I appreciate the chance to discuss that with the IESG. (Thanks Spencer for putting this back on to allow that to happen.) At the very least, I'd want to understand the degree to which this makes things worse and as-is the draft hasn't got enough information to allow such a calculation/estimate.
Comments for the ISE/Authors: - General: I find it very hard to see what's useful here that's not included in the references. Section 2 is so vague as to be utterly obvious. While a document with some real detail could arguably be a good ISE output, an arm-wave like this seems odd to me. - General: there should be some recognition that any logging of this nature generates highly privacy sensitive information that really is better deleted as soon as can be. - intro, para 2: "For various reasons it is necessary to log these mappings" That is both too coy and assumes necessity which I think is too strong a statement. - intro; why are megabytes per second scary? Seems like a small number to me. This ought be qualified as per binding to be a useful estimate - intro, last para: be better to synopsise or repeat the reqs here - it is not very "introductory" to use such opaqueness here - section 2: I wonder what a bad actor could do if they knew the block allocation scheme? was that considered? one can't I guess describe that given there is no block allocation scheme described in sufficient detail.
I'm interested to see the response to Alissa's discuss.
I agree with Stephen's point that the recommendations are obvious. Additionally, this document does not even reference a BCP (RFC 6302) on recommended logging procedures (as pointed out by Alissa). Given the increased security risk mentioned, the IESG needs to discuss what to do with this draft.
I think this document is related to a couple of documents produced by INTAREA, specifically RFC 6269 and RFC 6302. Given that RFC 6302 is a BCP and that Section 3 of this draft seems to further articulate on its recommendations, might this draft more properly belong in INTAREA?