IESG Narrative Minutes
Narrative Minutes of the IESG Teleconference on 2014-05-15. These are not an official record of the meeting.
Narrative scribe: John Leslie (The scribe was sometimes uncertain who was speaking.)
Corrections from: Martin
1 Administrivia
2. Protocol Actions
2.1 WG Submissions
2.1.1 New Items
Telechat:
Telechat:
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:
Telechat:
3.1.2 Returning Items
Telechat:
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
3.4.2 Returning Items
1305 EDT break
1310 EDT back, no rollcall
4 Working Group Actions
4.1 WG Creation
4.1.1 Proposed for IETF Review
Telechat::
4.1.2 Proposed for Approval
4.2 WG Rechartering
4.2.1 Under evaluation for IETF Review
Telechat::
Telechat::
Telechat::
4.2.2 Proposed for Approval
5. IAB News We can use
6. Management Issues
Telechat::
Telechat::
Telechat::
7. Agenda Working Group News
1339 EDT Adjourned
(at 2014-05-15 07:30:20 PDT)
draft-ietf-ccamp-rsvp-te-eth-oam-ext
I have only given this a quick look over and there is nothing here that bothers me from an applications area perspective. I would suggest a good scrub of what may or may not (no pun intended) be interoperability requirements text. There are many "must"s that appear to be very much about interoperability requirements and many "MUST"s that appear to not be. They seem randomly sprinkled. A review seems in order.
- section 2, para 2: the meaning of "co-routed" wasn't entirely clear to me, but I think that's probably ok if what you mean is the DA from one is the SA from the other and vice-versa. If it means something else, (e.g. that packets from DA to SA must traverse the same links as from SA to DA) that would be worth saying, or it would be worth referring to some document that defines co-routed more fully. - Table 1: You don't say what "reserved" means, but asssume it means "do not use"? - section 2, last para: I wondered what "subset" you meant for MIPs. - 3.1: I was surprised that so much is left for local config, in particular the CCM Interval - am I right that if you have different intervals setup then one of the MEPs will be constantly calling the LSP broken because CCM messages/frames won't arrive on time? (Though I see in 3.3.4 that you can send this info from one to the other, but I don't see where it says what to do with that value on receipt.) - 3.3.x, I hope IANA notice they're being asking for something (or you repeat it later) - 3.3.3: what if received a MEP ID is >=8192? (e.g. 2^14) (I also wondered why you want to save 3 bits but don't just reserve them) - 3.4: "PM" confused me briefly (cf. RFC7258:-) - section 5: defers to [OAM-CONF-FWK] - which draft is that? (I'm guessing https://tools.ietf.org/html/draft-ietf-ccamp-oam-configuration-fwk right?) And to RFC6060 which defers to RFC4872 which eventually says that "RSVP signaling MUST be able to provide authentication and integrity" - does that latter apply here? If so, (which I assume since that's a normative ref) wouldn't it be nice to remove the double indirection and just point that out directly.
I agree with Stephen on the nesting problem for the security considerations. Since RFC6060 points out that a hostile environment should be assumed, it would be good to mention other security protections with the appropriate links directly in the security considerations section of this document.
draft-ietf-l2vpn-vpls-inter-domain-redundancy
It would be nice if this document contained a clear definition of what is meant by "node redundancy". I think this is referring to PE nodes, but walking back to RFC 3985 I don't find a definition for that term, but as I progress through later RFCs I start to see "PE device" and later "PE node." I suspect that this is a well-understood term of art, but for the sake of readers who are trying to find their way through these documents for the first time it would help to make that clear. This stuck out for me because I at first interpreted "node" in the usual way that we use it in IETF protocols, and that definition of "node" doesn't make a whole lot of sense in the context of this document. I'm not in love with the sketchiness of the solution to state flapping described in section 7, but I assume that people who know more about this than I are satisfied with it, so I will say no more on the subject.
Thanks for working through the SecDir review.
The shepherd write-up says that this is BCP. The draft and data-tracker status say Standards Track. This needs to be clarified before it progresses.
Section 7: "In this document, ICCP protocol is deployed between two PEs or ASBRs. The two PEs or ASBRs should only be connected by a well managed and highly monitored network. This should be ensured by the operator." I understand what is meant here, but it might be good to be a bit more specific about the desired monitoring given recent discussions and RFCs about pervasive monitoring. I would suggest something like: "In this document, ICCP protocol is deployed between two PEs or ASBRs. The two PEs or ASBRs should only be connected by a network that is well managed and whose service levels and availability are highly monitored. This should be ensured by the operator." Section 9: s/author/authors/ (I assume.)
draft-ietf-trill-esadi
I appreciate the clear statement that the protocol described in this document is not backward compatible with ESADI as described in RFC 6325. However, this makes me question the migration strategy and interoperability issues. It looks like every rbridge attached to an end station in a particular Data Label needs to be speaking the same version of ESADI, or that some rbridges must speak both versions and work out which one to use. Questions that need to be answered are: * What happens when a 6325 implementation meets an implementation of this I-D? How will it handle the new LSPs/PDUs and how will the implementation of this I-D know what to do to correctly advertise its attached end stations? * What happens when an implementation of this I-D meets an implementation of 6325? How will it handle the obsolete LSPs and how will it learn about end stations attached to the 6325 implementation? * Is there a migration strategy from 6325 to this I-D? I suspect some of the answer is through neighbor determination, but since 6325 implementations are presumably in the wild there needs to be some discussion o how this hangs together.
Nit Section 1 Maybe it is US usage, but frames ingressed for that end station's MAC address didn't have a parsable meaning for me. Fortunately there is an explanation immediately after that suggests... "ingressed" == "sent into the network" "for" == "with a destination MAC address set to" --- Nit Some of the brackets in Figure 4 should say "bytes" not "byte" --- Ted will presumably want the authors to indicate how the multi-byte Length field in section 6.1 is encoded. --- In section 6.1 a variable length field "Reserved for future expansion" is a bit odd, IMHO. I see what you are doing for future compatibility, but the way of doing it is "different".
There is no mention of privacy here and I think that's needed - this seems to allow rbridges to shoot about a lot of information that could be considered privacy sensitive, esp. if that is logged. The document also talks about "other information" in a very vague manner. I realise that this protocol can be quite useful in managaging and securing campus networks, so the privacy issues ought be relatively easy to handle sensibly but having no mention at all seems just wrong. Even if this is limited to campus networks, in various countries, data protection issues may come into play. What I think I'd suggest is that there be some form of applicability statement that says what kinds of other information this is really for and also some text that dicusses the privacy implications of esp. logging the data passed about via ESADI.
- More IPR on TRILL, sigh. Ah well. - Please consider the secdir review [1] and Russ' related gen-art comment (in Jari's ballot). I think making changes for those would be good. [1] https://www.ietf.org/mail-archive/web/secdir/current/msg04737.html
I believe Russ' comment below is something that should be handled: > Section 8, the security considerations, say: > > ESADI PDUs can be authenticated through the inclusion of the > Authentication TLV as described in Section 6.3. > > However, there seems to me something missing. Section 6.3 tells how to derive a 256-bit authentication > key. It does not say how that key will be used to actually compute a message authentication code. I would > expect a reference to this information to be included in Section 6.3.
I support Stephen's discuss on privacy concerns and the need to elaborate on them. For the privacy concerns, having some experience on campus networks, it can be really helpful to pin point where an end node is when it is acting up (during a security incident). So there are clear advantages of having this tie to authenticated connections for the ESADI method as well as the ability to blackhole infected hosts. For privacy considerations, ESADI also tracks when end nodes move around, which should be mentioned as a consideration (good for security for blackholing and tied to NAC for network hygiene). If this information (location of end node) is logged, (basically - as I read it) the full network map could be logged and created, as well as maintained over time as it changes. On a campus network, privacy issues may arise when some sort of investigation is looking to identify where someone was at a particular point in time (or who did something). This has pros and cons. With other services (web logs in particular), some university admins have had the practice of removing logs after 30 days (by policy) to protect privacy and to avoid dealing with warrants - essentially if they don't have the data, they can't help. An example of that is web logs and dealing with the illegal download of media. Now we should not get into that full explanation of this example to explain the privacy issues, but a description of the risks to privacy when location over time could be pin pointed would be helpful for implementers to understand if they decide log and aggregate this information. They will want to consider appropriate storage periods. If it is stored at all, they could get subjected to record retention requirements as well (but I have not looked to see if any apply, I'm just highlighting that there could be requirements once they have and log this data). I also support Russ' request from the Gen-art review and agree with the proposed solution.
I support Adrian's and Stephen's DISCUSS points. It is incredibly disconcerting that there is no interoperability discussions in this document despite the claims in section 1.1.
In Section 4.4: s/EASDI-LSP/ESADI-LSP/ In Normative References section: "[RFCfgl] - Eastlake, D., M. Zhang, P. Agarwal, R. Perlman, D. Dutt, "TRILL (Transparent Interconnection of Lots of Links): Fine- Grained Labeling", draft-ietf-trill-fine-labeling, in RFC Ediotr's queue." s/Ediotr's/Editor's/
draft-ietf-straw-b2bua-loop-detection
I also agree with Adrian's comment. Decrementing by at least 1 but possibly more is a way of obfuscating hops taken.
Obfuscation of the number of hops traversed so far can surely be allowed provided that it always reduces the TTL.
Section 5: Does "decrement" here mean "reduce" or "reduce-by-exactly-1"? If the former, then you might even need to say to watch out in case the value is less than zero (or would be after decrementing). If the latter, which I guess is the case (since that's what's in 3261) maybe say so just to be sure. No big deal if you're ok with it as-is. I also agree with Adrian's comment.
In section 5: B2BUAs MAY perform the same actions for in-dialog requests, but doing so may cause issues with devices that set Max- Forwards values based upon the number of received Via or Record-Route headers. Don't you instead mean: B2BUAs SHOULD NOT perform the same actions for in-dialog requests, because doing so may cause issues with devices that set Max- Forwards values based upon the number of received Via or Record-Route headers.
I agree with Adrian and Stephen's comments on other for obfuscation discussed in the security considerations section rather than resetting the number of hops.
Two non-blocking comments: 1. You should expand "UAC" and "UAS" on first use. 2. -- Section 4 -- It is RECOMMENDED that B2BUAs implement the loop-detection mechanism for the Via header field, as defined for a Proxy in [RFC5393]. Why "RECOMMENDED" and not "REQUIRED"? It would be good to explain, to give guidance about when it might be appropriate not to.
I'm really glad to see this moving forward (because I've also talked to some of the folk who have had the pleasure of Max-Forwards=70 meltdowns). The recommendations seem clear and reasonable, and I'm happy to ballot Yes, with one nosy question. (I also agree with Barry's comment, and think I agree with Pete's as well, but you've already seen those). This text: If the received request did not contain a Max-Forwards header field, one MUST be created in any request generated in the UAC side, which SHOULD be 70, as described for Proxies in section 16.6 part 3 of [RFC3261]. points back to this text: 3. Max-Forwards If the copy contains a Max-Forwards header field, the proxy MUST decrement its value by one (1). If the copy does not contain a Max-Forwards header field, the proxy MUST add one with a field value, which SHOULD be 70. Some existing UAs will not provide a Max-Forwards header field in a request. in a proposed standard published in 2002. I'm looking at the definition in 20.22 Max-Forwards, which says This header field should be inserted by elements that can not otherwise guarantee loop detection. For example, a B2BUA should insert a Max-Forwards header field. So, what I'm wondering is, and a "no" answer would terminate my questions, which are pipelined just to avoid roundtrip latencies :-) - Are UAs that don't insert Max-Forwards still deployed? If so, - Would a spiral back out to a proxy or B2BUA that doesn't insert Max-Forwards still be vulnerable to the endless looping problem that this draft is addressing? If so, I wouldn't dream of asking you to figure out how to detect such a loop (and especially not when what you've already got is a huge improvement and doing so would hold you up), but I'm wondering if it would make sense to - point this problem out in the draft, and/or - consider whether a short BCP on "omitting Max-Forwards considered harmful" would have any positive effect.
Section 9: "Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA)." What is this doing here?
draft-ietf-salud-alert-info-urns
In the abstract: "The Session Initiation Protocol (SIP) supports the capability to provide a reference to a specific rendering to be used by the UA when the user is alerted." Rendering of what? The abstract shouldn't assume that the reader knows. In 8.2.2, it seems weird that the recipient would accept the "family" or "friend" indication from the sender. The security considerations address the larger point of trusting the sender generally, but I think this is different because it can only make sense when the sender has knowledge about the recipient's relationships. It seems like the wrong way to do this, and I am not convinced that it belongs here. I'm not raising it as a DISCUSS because it's not an interop issue and probably won't break the internet, but it seems weird and seems to have potential for abuse. What was the motivation for adding this? If it's to codify existing practice, it might be worth putting text in the security considerations addressing these specific indicators and saying that they are a bad idea, and are not recommended, but are included to address current practice. Otherwise (and modulo some other IESG review comments) the document is well written, easy to follow, and looks good. Thanks for doing it!
- I agree with Alissa's discuss point on section 16 and with the secdir review [1] on that topic. [1] https://www.ietf.org/mail-archive/web/secdir/current/msg04753.html - The private name + date thing seems over-complex really. - 9.2.6: you mean you want to add each country code to the IANA registry? Seems like a bad plan if so.
The Gen-ART review from Alexey and comments from Ben indicated that the unclear MUST requirement text needs a change. I can see that the authors are working on that. I think the text really needs to change, but since you have already taken on the task to do the changes, I am not raising a Discuss and are expecting Richard and others to make sure that the change happens.
Ah, it's so nice to be late and just agree with Alissa and Barry's DISCUSS points. Section 5 should be removed or moved to an appendix.
Nothing to add to the current AD reviews.
Hopefully, this is an easy one to clear up. I just want to make sure we address possible security and privacy concerns. I read through the draft and am unclear on how a source is determined to be a family member or friend (Section 9.2.2). If this is determined by the source, how does a receiver know it is accurate? Are there data sensitivity or privacy issues that need to be considered passing or storing this sort of information? It seems a little creepy to me (but maybe that's just me), I'd rather a number or name pop up without the phone system knowing who everyone in my life is to me. Is this determined by the source as is stated or in a local comparison by the receiver as is done now with contact lists, etc.?
Thanks for addressing Stephen & Alissa's comments. I'm also interested to see the SecDr comments resolved, Stephen provided a pointer.
-- Sections 9.1, 9.2, 10.1 -- I worry that we're painting ourselves into an undesirable corner here by using Standards Action for the registration policies. Is it truly inappropriate to use Specification Required or Expert Review, and to let a designated expert that the IESG appoints stand in for (1) overall IETF review and (2) the demand that the registration be done in a Standards Track RFC? We have too many cases when we've later regretted using Standards Action or IETF Review (the registration of a URN NID being one of them; we're in the pocess of changing that policy in the urnbis working group). And especially if you want other standards outside the IETF to use these, requiring them to get an IETF Standards Track RFC or to use private names doesn't seem reasonable. Can you please explain the reason for holding to Standards Action, and the harm that would be caused by using some form of expert review instead?
This is a good, thoroughly thought-out document. I can't tell you how many times I typed a quick comment note as I was reading, only to find it addressed a paragraph or two later. -- Section 6.2.1 -- Because the call-waiting information may be subject to the callee's privacy concerns, the exposure of this information shall be done only if explicitly required by the callee. I think you mean explicitly "permitted" by the callee, no? -- Section 6.2.2 -- Is this not also subject to privacy concerns in the same way that a call-waiting signal is? If someone calls my home phone and knows that the call is being forwarded, she can assume I'm not home and go burglarize my house. -- Section 6.3 -- Just a note on this, which you can take or leave as you please: I find that when I'm not familiar with the tones that a country uses, I may actually be confused by hearing them: perhaps a "busy signal" ("engaged tone") from one country sounds to me like a "ringing" tone, and I wait on the line for a response... or the other way 'round, or something like that. That sort of thing has happened to me, so it's not just hypothetical. It's not clear that it's a good idea to give callers the tones that are meaningful to the callee... and might be better to use tones that mean something to the caller. I'm sure you've talked about this, so all I'm wondering here is whether it's worth saying a few words in this section. What's here makes it sound as though it's always better to provide the caller with the callee's tones. What it says is decidedly *not* true for me, as one example. -- Section 7 -- For the contact information, you give <rai@ietf.org>, and attribute it to the "RAI Area Director". Is there actually such an email address? Is it a general RAI area mailing list? Or do you mean <rai-ads@tools.ietf.org> ? -- Section 10.2 -- Once an organization obtains the right to use a particular <provider> for constructing <private-name>s, it will retain that right forever, unless it transfers that right to another organization. How does an organization obtain that right, and from whom? How does it transfer the right? I guess that's meant to be specified in Section 10.3, so at the very least a forward reference is in order. But perhaps it's better still to delete this paragraph entirely, and roll the essence of it into Section 10.3, where the rest of that thought lives. -- Section 10.3 -- Should we be specifying intellectual property rights in our standards, when those rights don't apply to the IETF? We should probably at least have Jorge look at this section and advise us. And do you really expect domain owners to research whether they're the first to hold their domain names, in order to know whether they need to incorporate a date or not? I suspect that dates will be used very fluffily, if at all. -- Section 10.4.2 -- However, before defining such a URN, the organization should verify that the set of calls to which the URN applies is not a subset of the set of calls for some existing URN. If it is a subset, the extension URN should be a subdivision of the existing URN. I think I know what this means, but I had to read it three times before I thought I was sure. Maybe a bit of rewording or more explanation would be useful. -- Section 11.1 -- Bullet (b) is something that has been mentioned before, but in the earlier contexts I thought it was optional. Bullet (b) is worded so that is not optional ("the UA repeatedly removes the final <alert-ind-part> of the URN until") -- describing it as what is done, as opposed to what can (or MAY) be done, makes it an integral part of the protocol. Is it meant to be what is always done, or is it meant to be optional? When selecting from the set of equally effective signals, no signal should be chosen if a less-specific signal is also in the set. I find the negative plus the "if less is" to be a little confusing. I wonder whether non-native speakers, or less-than-careful readers might be prone to misunderstanding it. Does this work for you?: NEW When selecting from the set of equally effective signals, the least specific signal in the set should be chosen. END
I support Alissa's and Barry's DISCUSS points.
Section 10.3: I think it's unnecessary and out of the IETF's scope to be defining new intellectual property rights in URNs. I can understand the desire to provide some warning to organizations to say "don't squat on someone else's <provider> name," but ultimately if a registry is not being defined, there is nothing the IETF can do to require organizations to follow that guidance. If it's that important, then the proper way to handle this would be with a registry. I think it would be reasonable to retain the suggestion that, at the time when a <private-name> is being defined, it should be defined by the registered owner of the corresponding <provider-id> (second para of 10.3), but drop the rest (third para of 10.3). When domain name ownership gets transferred, the transferor and the transferee will have to work out who maintains the definition of the <private-name>'s URNs. (As an aside, the date stuff seems superfluous as well. I have a hard time believing it will get used, but I'm assuming there is some reason for it to be there in the first place? I see that there is some precedent for the provider+date structure in RFC 4198. Section 16: Even with authorization, the caller or callee may want to protect the confidentiality of these alerts (along with other headers). I agree with the SECDIR reviewer's suggestion about mentioning the use of TLS here, with appropriate caveats about difficulty of deployment.
Section 5: "REQ-4: has been deleted. To avoid confusion, the number will not be reused." This reads oddly. If you want to keep this in, something like this would be better: "REQ-4: This requirement appeared in earlier versions of the document, but has been deleted. To avoid confusion, the number will not be reused." On the other hand, the REQs are never referenced again in the document as far as I can tell, so is it really that hard to re-number them? Or is REQ-4 left in because the requirements are referenced in other documents? REQ-10: s/uncomon set/uncommon set/ REQ-16: s/not subject of/not the subject of/ REQ-18: s/not subject of/not the subject of/ Section 6.2.1: "Because the call-waiting information may be subject to the callee's privacy concerns, the exposure of this information shall be done only if explicitly required by the callee." Agree with Barry's comment here. Seems like if any of the parties would be "requiring" this, it would be the caller, not the callee. But in any event it should be up to the callee to decide whether to expose this info. Section 7: s/ and [RFC3406]/ and [RFC3406]./ Section 8.2: s/no-operation"alert" URN/no-operation "alert" URN/ Section 8.2.2: The inclusion of "friend" and "family" made me wonder why an indication of "work" or "professional" (as opposed to friend/family) was not included. Work colleagues may be internal or external, so this would be a separate classification from all of the ones already listed. I would guess usage of this would be desirable if "friend" and "family" are as well. Section 10.1: s/an new <alert-category>/a new <alert-category>/ Section 10.2: "Within a URN, all <alert-label> components that follow a <private- name> but are before any following <private-name>s are additional private extensions whose meaning is defined by the organization defining the <private-name>." The phrase "the <private-name>" is possibly ambiguous. I think what is meant at the end of this sentence is "the organization defining the <private-name> immediately prior in the hierarchy." "(In either case, the organization SHOULD use the existing URN for its purposes.)" This seems a bit superfluous. It's like saying organizations should use the URNs they mint, but there are cases where they shouldn't. Isn't that what will happen anyway regardless of what this draft says? Section 14: s/A A SIP proxy/A SIP proxy/
draft-ietf-mpls-psc-updates
This document should probably make reference to draft-ietf-mpls-tp-psc-itu, although the main reference is, of course, in the other direction. I suggest a new 2nd paragraph in Section 1 that reads... It should be noted that [I-D.ietf-mpls-tp-psc-itu] contains protocol mechanisms for an alternate mode of operating MPLS-TP PSC. Those modes are built on the message structures and procedures of [RFC6378] and so, while this document does not update [I-D.ietf-mpls-tp-psc- itu], it has an impact on that work through its update to [RFC6378]. You would then need to add [I-D.ietf-mpls-tp-psc-itu] as an Informative reference.
From the title, abstract, introduction, I see words such as updates, rules, recommendations, corrections, clarifications. I'm unable to tell if there will be backward compatibly issues between this future RFC and RFC6378 And sorry, I haven't reviewed all the technical details of the update, to make up my mind. Is this document just text clarifications, or should http://tools.ietf.org/html/rfc5706#section-2.3 be considered? If the former, clarify this early in the document. Otherwise, discuss the migration path. I was about to file a DISCUSS on this, but a quick discussion was beneficial. He wrote: 2.1 Just a statement for clarity 2.2 Just a statement for clarity 2.3 Clarifies error handling. Might change behavior s.t. a broken message previously accepted is now rejected. This is not a b/w compatibility issue 3. This could change implementation behavior (if the previous implementer was a literalist fool), but the impact is to make a broken implementation work, so that is not a b/w compatibility issue 4. Describes how to behave to achieve interop or report inability to interop. Old implementations may have winged it, but probably never had the issue because mismatches would not actually have happened. No b/w compatiblity issues. 5. This fixes a bug in an obscure double race condition. In the event that a pair of old implementations hit this case they would have frozen, so fixing it is not a b/w compatiblity issue. 6. Is effectively a statement for clarity. Working implementation I know f already do this. I do know a broken implementation that doesn't do this, with the result that it simply doesn't work. So b/w compatibility is not an issue. I now understand that there are no "backward compatibility issues". Simply add: "This document does not introduce backward compatibility issues with implementations of RFC 6378"
Thanks for addressing the security considerations. I'll look for the updated text in the draft from that review.
I have no objection, and I think we should do more clarification documents when we find situations such as this. I do think this could clarify a bit better, so please consider: Section 2.1 says "network bit order". Section 2.2 says "network byte order". Are they meant to be different things? If not, pick a consistent term. In either case, a reference defining the term would be useful, just to be sure -- you're clarifying, so it's better clarify as clearly as possible. I actually still find Section 2.2 somewhat convoluted, as the mention of "The TLV Length" is unclear -- it seems out of place, there in the middle of the detail about individual TLVs. May I recommend a bit of reorganization here?: OLD [RFC6378] provides the capability to carry TLVs in the PSC messages. This section defines the format to be used by all such TLVs. All fields are encoded in network byte order. Type field (T): A two octet field that encodes a type value. The type values are recorded in the IANA registry "MPLS PSC TLV Registry". Length field (L) : A two octet field that encodes the length in octets of the Value field. The TLV Length is the sum of the lengths of all TLVs in the message. The length of a TLV is the sum of the lengths of the three TLV fields, i.e., the the length of the value field + 4. The value of this field MUST be a multiple of 4. Value field (V) : The contents of the TLV. This field MUST be a multiple of 4 octets and so may contain explicit padding. NEW [RFC6378] provides the capability to carry TLVs in the PSC messages. All fields are encoded in network byte order. Each TLV contains three fields, as follows: Type field (T): A two-octet field that encodes a type value. The type values are recorded in the IANA registry "MPLS PSC TLV Registry". Length field (L): A two-octet field that encodes the length in octets of the Value field. The value of this field MUST be a multiple of 4. Value field (V): The payload of the TLV. The length of this field (which is the value of the Length field) MUST be a multiple of 4 octets, and so this field may contain explicit padding. The length of each single TLV is the sum of the lengths of its three fields: the length of the value field + 4. The overall TLV Length field in the PSC message contains the total length of all TLVs in octets. END
I'm clearing my Discuss assuming something like Adrian's proposed text makes it into the doc. Adrian's proposed text is : OLD 2.3.2. Well-formed but unexpected TLV If a message is deemed to be properly formed, an implementation SHOULD check all TLVs to ensure that it knows what to do with them. A well-formed but unknown TLV value MUST be ignored, and the rest of the message processesed as if the ignored TLV did not exist. An implementation detecting a malformed TLV SHOULD alert the operator as described in Section 2.3.1. NEW 2.3.2. Well-formed but unknown or unexpected TLV If a message is deemed to be properly formed, an implementation SHOULD check all TLVs to ensure that it knows what to do with them. A well-formed but unknown or unexpected TLV value MUST be ignored, and the rest of the message processed as if the ignored TLV did not exist. An implementation detecting a malformed TLV SHOULD alert the operator as described in Section 2.3.1. END My Discuss was: --- This should be a easy Discuss to clear, especially if I don't understand what's going on ... 2.3.2. Well-formed but unexpected TLV If a message is deemed to be properly formed, an implementation SHOULD check all TLVs to ensure that it knows what to do with them. A well-formed but unknown TLV value MUST be ignored, and the rest of the message processesed as if the ignored TLV did not exist. An implementation detecting a malformed TLV SHOULD alert the operator as described in Section 2.3.1. "unexpected" and "unknown" don't mean quite the same thing to me (I think from the paragraph you mean "unknown"), but the Discuss is that the last sentence is saying what should happen if the TLV is malformed, which was 2.3.1, and the section doesn't say what to do if the TLV is unexpected, or unknown or whatever this section turns out to be about. Cut and paste error from someplace? Could you take a look at this more closely?
draft-ietf-mpls-extended-admin-group
Minor nit in the introduction, paragraph 3: bitmask. This means that 32 bits can only (cleanly) represent 32 metro areas. It should be obvious that 32 may not be enough even for a US-based network, nevermind a worldwide network. This may well be too nit-picky, but this text can be read as implying an editorial assumption that the reader would naturally assume a US-based network unless otherwise specified. This could be used to beat up the IETF for being U.S.-centric, which people apparently still do. I suspect this assumption wasn't intended, but rather that you were continuing the example earlier in the paragraph where multiple U.S. cities were listed. However, if you care to, you might want to change this to "single-country" instead of "US-based." Or you can ignore this very minor nitpick, and it very likely won't matter. In section 2.2: By convention, the existing Administrative Group TLVs are numbered 0 (LSB) to 31 (MSB). The EAG values are a superset of AG. That is, bits 0-31 in the EAG have the same meaning and MUST have the same values as an AG flooded for the same link. If an EAG's length is more than 4 bytes, numbering for these additional bytes picks up where the previous byte left off. For example, the least significant bit in the 5th byte of an 8-byte EAG is referred to as bit 32. If I am reading this correctly, what this means is that the first byte in the TLV contains bits 24-31, the second bits 16-23, the third bits 8-15, the fourth bits 0-7 and the fifth bits 32-39. This seems counterintuitive and likely to promote mismatches between the UI and the wire format on different implementations, if an implementor gets this wrong. My concern is that two different devices from two different vendors could wind up accidentally being incompatibly configured in a way that would be difficult for the end-user to debug if such a mistake were made. Did the working group consider this possibility? It might be worth adding a small amount of text that calls attention to this counterintuitive numbering of bits more explicitly, so as to make such a mistake less likely. I'm not raising this as a DISCUSS because a careful read of the text can produce only one interpretation, so a wrong implementation would not be following the spec.
When both AG and EAG are sent the AG colours are sent twice. That always bothers me since its always possible that someone reads the wrong bits. The spec is correct as-is I think, but just wondering if you considered not sending those 32 bits twice? (i.e. if AG and EAG both sent, then bit 0 of EAG is the 33rd colour.)
Agreed with Barry's DISCUSS point 1, and I believe Barry's new proposal improves the doc. I've not yet seen an answer to Nevil's question in the OPS DIR review. 4. Are there any backward compatibility issues? Section 2.3.1 covers AG and EAG coexistence. I was puzzled by the paragraphs in 2.3.1 that says "If both an AG and EAG are present, a receiving node MUST use the AG as the first 32 bits (0-31) of administrative color and use the EAG for bits 32 and higher if present." Since the first 32 bits of an EAG should be the same as the first 32 bits of an AG, why not change over now, and use the first 32 bits of the EAG? A few typos: p3: s/restrictions, allow for/restrictions, allowing for/ p5: a/assumption is than an/assumption is that an/ p6: s/caled/called/
I have nothing new to add, but did like Alia's suggestion for the security considerations section.
I think this is a good document, and have two points I'd like to discuss before approval. The first is an easy one: -- Section 2.3.2 -- I hate to pick on this, I really do -- because I know what you're trying to say -- but there's too much wrong with this bit: Each implementation is free to choose its own method for handling this question. However, to allow for maximum interoperability an implementation SHOULD treat desired but unadvertised EAG bits as if they are set to 0. "Free to choose" and "SHOULD" really don't go together, at least not with the definition of "SHOULD" from 2119 and any meaning of "free to choose" that I can think of. What's more, you then have a "MUST NOT" later in the paragraph that should probably be a "SHOULD NOT" (because it goes with the "SHOULD". On the other hand, if you really mean that "MUST NOT", then the "SHOULD" ought to be a "MUST". Oh, and then there's a "MAY" in the next paragraph, which makes the whole thing worse. Oy. Because I really *do* hate to pick on this, and because I think I do know what you're trying to say, let me try proposing alternative wording for the last two paragraphs that should (ahem) keep us 2119-purists happy (or at least comparatively happier). As a side effect, it makes subjunctive-mood-pedants somewhat happier, as well (changing "as if they are" to "as if they were"): NEW To allow for maximum interoperability, an implementation SHOULD treat desired but unadvertised EAG bits as if they were set to 0. Consider the case where a node wants to only use links where the 127th bit of an EAG is set to 1. If a link is only advertising 64 EAG bits, clearly the 127th EAG bit is not defined - that is, it is neither explicitly 0 nor 1. The node that wants the 127th EAG bit to be 1 will not use this link when implementing the recommended behavior, as the assumption is than the unadvertised 127th bit is set to 0. That said, each implementation makes its own choices based on necessary constraints, and there might be reasons to provide other strategies for handling this case. A strategy that deviates from the behavior this document recommends SHOULD be configurable to use the recommended behavior, in order to provide maximum interoperability. END I think inverting the advice -- putting the desired behaviour first -- is a better choice anyway, because it highlights what you want implementations to do... and only after that does it backtrack and admit that, well, implementations will ultimately do what they want. The second is probably somewhat harder: -- Section 3 -- Is it really the case that there are no possible issues raised by suddenly having an open-ended number of EAG bits, having a different number of EAG bits than are expected or desired, and/or having uncertain behaviour in the face of a desired bit's not being there? I'm not sure of the answer to that, but I am sure that it strikes me as very much open to issues, and I want to make sure you explicitly thought about it carefully and decided that there aren't... and that "no new security considerations" isn't just what we're accustomed to putting in when we think we're making a minor change.
I do agree that Barry that I'd prefer to see clearer wording in Sec 2.3.2. I really don't see a reason that this is a SHOULD instead of a MUST for understanding that unsignaled colors MUST be assumed to be 0. I'm slightly concerned that we'll end up in a situation where a color can have three values - 0, 1, and unknown - and thus foster different behaviors. I also found it slightly confusing in this section about being able to not advertise some EAG bits. What I think is meant is that a router only needs to send colors up to the word including the highest set bit value. I.e. if bit 74 is set, then bits 0 to 95 will be sent. With the encoding, there's not a way of sending bit 528 without having sent all the lower bits. For the Security Considerations, I agree that there aren't actual new attacks created - but I would recommend mentioning what the actual constraints on the EAGs adding data are and how they are limited by the protocol or media constraints (mentioned in Sec 2.1). In the intro, it says: "EAG's intended use case is within a single domain. As such, this document provides no support for signaling EAG." This is also restricting it to ingress full path computation since midpoint LSRs will not be able to see the constraints. Could you please add such a clarification?
I support Barry's point on section 3 and the security considerations section.
Section 1: s/allow for an arbitrary/allowing for an arbitrary/ Section 2: s/bits with an AG or EAG/bits within an AG or EAG/
draft-ietf-ipsecme-esp-ah-reqts
Barry caught one of my concerns... I agree that "SHOULD-implement" is open to confusion. --- Please consider renaming 2.5. Summary of Changes to 2.5. Summary of Changes from RFC 4835 Also please consider adding an introductory line of text in that section to clarify what it is talking about. --- It would appear that the editor note in Section 6 is no longer needed. At least, I removed it and idnits was quite happy.
To Stephen's point and Pete's: I suggested "REALLY SHOULD NOT" [RFC6919]
I am glad Barry and Adrian have already commented. I roll my eyes, wonder why this document did not reference RFC 6919, and move on with my day.
-- Section 3 -- Both confidentiality and authentication SHOULD be provided. If confidentiality is not needed, then authentication MAY be provided. Confidentiality without authentication is not effective [DP07] and SHOULD NOT be used. We describe each of these cases in more detail below. This says that if you confidentiality is not needed, authentication is *entirely* optional, and there is *no* recommendation being made about the use of authentication alone. Discussion with Paul indicates that that isn't what's meant, but that (1) the WG wasn't able to agree on better text, and (2) tweaking that sentence isn't going to affect implementations anyway. I think the failure here is in trying to stuff 2119 language in. Because the next paragraph goes into more details and uses the 2119 key words (and I think it gets it right), a good option might be to lose the 2119 key words in this short paragraph, and just have this be a lead-in to the next one. This one explains what you're getting at, and the next one puts in the details with the 2119 language. Some totally editorial stuff... no response needed either way: -- Section 4 -- Because you use "SHOULD-", it strikes me that "SHOULD-implement" might be misunderstood to refer only to "SHOULD-" algorithms. I suggest changing it this way: OLD The algorithms listed as MAY-implement are not meant to be endorsed over other non-standard alternatives. All of the algorithms that appeared in [RFC4835] are included in this document, for the sake of continuity. In some cases, these algorithms have moved from being SHOULD-implement to MAY-implement algorithms. NEW The algorithms listed as "MAY implement" are not meant to be endorsed over other non-standard alternatives. All of the algorithms that appeared in [RFC4835] are included in this document, for the sake of continuity. In some cases, these algorithms have moved from being "SHOULD implement" to "MAY implement" algorithms. END -- Section 6 -- I wouldn't normally pick on anything in the "Acks" section, but there's this: Much of the wording herein was adapted from [RFC4835], the parent document of this document. Actually, only the Security Considerations and one paragraph from the Introduction survive from 4835, and I'd hardly call the rest "adapted". If you want to leave it as it is, that's fine and this is the last you'll hear from me about it. But it might make sense to reword that to acknowledge the role of 4835 relative to this document somewhat more accurately.
draft-ietf-appsawg-uri-get-off-my-lawn
In section 1.1: o Protocol Extensions ("extensions") - specifications that offer new capabilities to potentially any identifier, or a large subset; e.g., a new signature mechanism for 'http' URIs, or metadata for any URI. "potentially any" is a really awkward construction which I first read as a typo, and which potentially could confuse non-native speakers. The RFC editor will probably notice this as well, but I would suggest phrasing it thusly: o Protocol Extensions ("extensions") - specifications that offer new capabilities that could apply to any identifier, or to a large subset of possible identifiers; e.g., a new signature mechanism for 'http' URIs, or metadata for any URI. Aside from this nit, this is a really good document and I'm happy to see it moving forward!
I am disappointed by the lack of examples of operational difficulties in the last paragraph of 2.3 and the second paragraph of 2.4. I also don't understand the SHOULD NOT (instead of the MUST NOT) in 2.4. In 2.4, please strike "is not conforming; doing so". In 2.5, please strike "is not conforming, and".
-- These were my discuss points. I still need to update them based on the discussion (and will hopefully before the end of the telechat;-) but wanted to clear before the start of the call. 1) Section 2 uses terms from 1.1 to distinguish various things, but 1.1 is very vague in defining the set of specifications to which this BCP is meant to apply. Why won't this cause loads of argument later about so-and-so I-D that e.g. defines {whatever}/myapp being covered by this or not? Seems to me it will. I'll clear on this once you've responded, since we already have those arguments so we're no worse off in that respect with this, but I'd like to at least ask if you can better define the target specifications to which you want this BCP to apply. 2) 2.2: what about the port number in authority, doesn't that need a mention? 3) 2.3 says {whatever}/myapp is bad, and depends on the intro for why ("operational difficulty") but that part of the intro only IMO shows that collisions are bad, (see my comment below) which does not seem to justify the conclusion that this (fairly common) practice is really bad since {whatever} can be chosen to make collision probability as small as you like. I don't get the justification for this to be honest. 4) 2.4, 3rd para: is this outlawing the practice of defining how to handle your message as an HTTP form? E.g. as an alternative to a POST body. Is that a good plan? And why "SHOULD NOT" - when is it ok to do this? 5) section 3: I wondered which of these techniques is in wide-spread use? If none, then how is this credibly a BCP? Is it not the case that the techniques that are outlawed here are is more common use than those that are recommended? (To clear this bit for me, a simple statement of the reality would be sufficient, though another LC might be warranted then perhaps.) --- These are my (old) comments - general: BCP UPDATES STD. My head spins, but I don't complain:-) I hope a) nobody does complain, and b) nobody tries to explain to me why that's ok, or not ok:-) - general: I wondered if the authors or appsawg have really checked if this all makes sense for all existing URI schemes. Isn't having done that part of the work here? (I'm not trying to trap you with an undisclosed counter-example for when you say you have btw:-) - general: I was surprised you don't list some of the existing counter-examples (e.g. robots.txt) - intro, "Dilution" - Are missing a bit of the argument? Is the "missing" bit is that structured data from non-owner specifications is quite likely to contain ephemeral data as values, e.g. "recordNo=3893243" - intro, "Operational difficulty" - this overlaps with "Collisions" - couldn't you craft an example that doesn't? If not, is this really a separate point to make here? - intro, "Client assumptions" - the example only leads to undesirable behaviour if someone deploys with "mySig" and not "sig", so I'm not sure this is relevant here as either a) the specification said you could use another name in which case that's a dumb spec, or b) the server isn't implementing the spec. Neither seems really due to representing the structured data in the URI. - intro, 2nd last para: what is an "independent standard"? I think saying "IETF specification" would be better. (And nittily: s/usurp it./usurp that./) - intro, last para: s/explains/explains some/ or are you claiming there are no others or that any others discovered or invented ought also update this proposed BCP? - 1.1 - the section title lead me to believe that types of person and not types of specification would be identified, which isn't what's in the body of the section. Maybe s/specification/specification writer/ generally in the body or change the title? - 2.1 - does "SHOULD NOT preclude" mean that you SHOULD define which URI schemes work with your protocol and which do not? I think this'd be better stated as a positive really, for clarity. - 2.3, s/cannot/ought not/ or use a 2119 term. People clearly can, and have written specs with "/myapp" hardcoded therein. - 2.4, 2nd para: I don't get why this is true. - 2.4, 3rd para: What does "MUST NOT specify" mean really? Its a pretty odd phrase. - 2.4, last para: not a great example since a signature can be verified or not by its value. - 2.5: I don't get why only media types are allowed to specify fragment syntaxes. I mean why does that make sense? If its for purely historic reasons, maybe say that. (And why can't I dress any old crap up as a media-format and get around this BCP that way?) - section 3: I don't myself buy that collision improbability isn't a good enough solution, but that's just my opinion (hence not a discuss), but shouldn't you say why? E.g. why is a prefix of "myapp_rand()_" not good enough?
As Alissa points out, I suspect that a lot of the considerations here are specific to HTTP. I'm concerned that this document reflects a few assumptions about URIs that look really odd when you compare them to what we normally assume about protocol fields. In general, this document seems to reverse an important implication. The following are not equivalent: protocol => format format => protocol The former is usually true; the latter usually false. Protocols define formats all the time -- that's 80% of what a protocol is. This document seems to assume, however, that just because one protocol uses a given format, then anything that uses that format belongs to that protocol. This seems like an assumption that we don't really make anywhere else. If an HTTP-based protocol were to require request bodies to have a particular content type, for example, it would be entirely non-controversial. We would not assume that all requests with that content type belonged to that protocol. Why are URIs privileged? In other words, this document says that it's OK for protocols to extract information from a URI, but they have to take what they get -- they can't require that the URIs have any particular format. This seems dramatically different from how other protocol fields are handled. Usually applications are free to examine received protocol elements however they like, and say "No, that's not OK" if they don't like the contents. Why are URIs privileged? Now, I don't entirely disagree with the risks called out in the document. There is a risk of confusion if you specify components in a URI, and there is a risk of rigidity if URIs are constrained in bad ways. My problem with this document is more with regard to how it approaches these risks. Rather than calling out these risks and advising protocol designers on how to avoid them -- while still allowing URIs to be structured by protocols, making informed trade-offs -- the document forces a risk judgement on all future protocols.
I support Stephen & Alissa's discusses and will watch for the outcome. Thanks
My Yes is anticipating a resolution to discussions with Alissa and with Stephen (and anyone else who's balloting after me), but this seems exactly the kind of BCP we should be producing, and I for one have no concerns with updating a standards-track specification with a BCP that's clear that it's doing the update.
(1) I had the same thought when reading this as Stephen commented about in reference to whether all of this guidance makes sense for all URI schemes, or whether it is actually motivated by activity going on in relation to http: and https: and not other schemes. In general the guidance seems widely applicable but I'm a little uncomfortable assuming that there aren't any situations where sip: or tel: URIs might be used differently enough that deviating from what this document says has in the past or will in the future seem like the right thing to do. So it would be helpful to hear about why the guidance in this document makes sense for all URIs. (2) Section 2.1: "A specification that defines substructure within a URI scheme MUST do so in the defining document for that URI scheme, or by modifying [RFC4395]." I don't understand the bit about modifying RFC 4395. First of all, RFC 4395 is quite general, so it seems odd that a single prospective scheme specifier would go modify that document just to be able to define a substructure within a URI scheme. Furthermore, I'm wondering if the real point here is to say that once scheme substructures are initially defined, they cannot be modified in the future. I don't really read that anywhere in RFC 4395, but if that is the implication here, why not just make that statement another recommendation of this BCP, and skip the bit about modifying RFC 4395?
Section 2.1: "However, applications SHOULD NOT preclude the use of other URI schemes in the future, unless they are clearly specific to the nominated schemes." "Clearly specific to the nominated schemes" is a vague enough standard that I wonder whether this is really worth saying at all. That is, isn't this what specifications generally already do anyway? What is driving spec authors to overly constrain future URI scheme use other than the "specificity" of the application in question?
draft-ietf-rtcweb-use-cases-and-requirements
Nice document, thanks. But I have some issues to check. Nothing huge I'd say. (1) F13: Authenticate is ambiguous here (and in WebRTC generally). There appears to be an understated need for an IdP here, and its really the IdP's that are authenticating (one another and) the endpoints. Did the WG discuss any form of endpoint auth that's based on e.g. an SSH leap-of-faith like setup where the endpoints can re-authenticate one another after a first contact? It'd be a bad thing if the WG made that impossible and effectively required IdPs I think. (2) F20: Is there not a missing requirement that one ought not be able to easily consume the bandwidth of someone else's TURN server just because you once made a call via that? (3) F36: Its not clear to me that this can ever be done safely, since JS code with this privilege can take screenshots every 10ms and hence get everything. A "must" level requirement seems quite inappropriate even if there is a real requirement there to allow some support for screensharing. (4) 3.3.12.1 - if the sound file can be local and played as a result of gameplay then that implies some form of authorization for access to files on the local filesystem - is that requirement actually being worked? (5) 6.2: why is revocation only "expected" and not a MUST? And why doesn't this section have any 2119 terms? I think privilege revocation has to be a 2119 MUST. (But am open to argument that that MUST ought apply to the API not protocol.)
- intro: I don't get how the document is planned to be used later, but that's ok. For now however, I'm reading the requirements as if those are the ones that the WG are working to, since I've no other sensible choice really. (And the plan confuses me more if W3C are taking these as real but rtcweb isn't.) - F10: heh, which video codec exactly? :-) - F11: Is 2804 the exactly right reference, maybe 7258 is worth adding (now its published) as that also envisages non-targetted PM whereas 2804 is really only considering targetted wiretap. Or maybe refer to both. - F19: Is acquiring call metadata via TURN considered a breach of F11? If not, then shouldn't that also get a mention somewhere? - F35: the title of 3.3.9 is about files but the requirement is about data, seems like a mismatch - 3.3.10: I've heard this use-case before. It was outlandish then. Not objecting though.
This document is a mishmash of UI requirements, local browser implementation requirements, and protocol requirements, with no distinctions being made among them. Given the IETF's notorious lack of skill in producing good UI work, and a great deal of text over the years indicating that we don't do UI and we don't constrain local implementation choices when they don't affect interoperability, I'm very dubious about the worth of this document. Then the introductions says: This document was developed in an initial phase of the work with rather minor updates at later stages. It has not really served as a tool in deciding features or scope for the WGs efforts so far. It is proposed to be used in a later phase to evaluate the protocols and solutions developed by the WG. So the document was not found to be of use on input to the WG, and it's not clear to me what exactly happens if the evaluation concludes that the protocols and solutions don't meet these requirements at the end. I don't see the point in publishing this document, certainly at this time. Moreover, there are things in this document which strike me as problematic. I suspect things like those said in 3.3.1.1 will end up being (inappropriately) used as a bludgeon later, for no good reason: "Well, the requirements document published by the IETF says that you have to have a self-view during session establishment. You don't have self-view during session establishment. You're non-conformant and therefore will not be allowed in the market." Even mentioning self-view during session establishment in an IETF document gives me the creeps; I can imagine UIs with the feature, and I can imagine them without. Some of the requirements seem awfully suspicious. For example: F13 The browser must encrypt, authenticate and integrity protect media and data on a per-packet basis, and must drop incoming media and data packets that fail the per-packet integrity check. In addition, the browser must support a mechanism for cryptographically binding media and data security keys to the user identity (see R-ID-BINDING in [RFC5479]). Maybe "per-packet encryption" means something magical, but can't we imagine a protocol decision that ends us up with stream-based or body-based encryption that is not "per-packet" that would still be perfectly reasonable? I wonder whether this document is over-constraining. And finally, we have stuff like this: "3.3.10. Hockey Game Viewer" "3.4.2. Fedex Call" Cute, but seriously? Do we really need cultural references like this? I can't support the publication of this document. I won't stand in the way if it has consensus behind it, but I don't see the point.
I have not seen any reply to Tina's OPS-DIR review, dated from April 25th. That makes it a DISCUSS to me, even if not all points in Tina's feedback are DISCUSS-worthy. See http://www.ietf.org/mail-archive/web/ops-dir/current/msg00274.html
- References please Assuming that ICE will be used, this means that the service provider would like to be able to provide several STUN and TURN servers (via the app) to the browser; selection of which one(s) to use is part of the ICE processing. - But in addition to this, the users can send and receive files stored in the file system of the device used. 3.3.9.2. Additional Requirements ---------------------------------------------------------------- REQ-ID DESCRIPTION ---------------------------------------------------------------- F35 The browser must be able to send reliable data traffic to a peer browser. ---------------------------------------------------------------- Do you want to say? F35 The browser must be able to send files to a peer browser. Does "data traffic" = file? Also, reliability is implicit, not? - particiapants -> participants - section 3.3.11. Multiparty video communication, 3.3.12, and potentially so other: Any connection with "Use Cases for Telepresence Multistreams", RFC 7205? - Why are the API requirements in an appendix? Because there are not normative? If so, make it clear.
I support Alissa's discuss and appreciate you addressing her security concerns. In Section 6.2, can you repeat the requirement to prevent wiretapping in this list? Other security requirements are repeated and this one if important in light of the revelation on GHCQ gaining access to Yahoo web chat a couple of months ago.
The change log says that this was done in -11: o Removed the "Conventions" section with the key-words and reference to RFC2119. Also changed uppercase MUST's/SHOULD's to lowercase. But some of it was reverted: the "Conventions" section and the 2119 reference re-appeared in -12, and remain there in -14.
Thank you for addressing Alissa's DISCUSS, and I agree with the proposed text. I noticed a couple of things other ADs didn't comment on yet: 3.3.12.1. Description Note: the difference regarding local audio processing compared to the "Multiparty video communication" use-case is that other sound objects than the streams must be possible to be included in the ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ spatialization and mixing. "Other sound objects" could for example be a file with the sound of the tank; that file could be stored locally or remotely. This is really rough. Perhaps "other sound objects must be allowed to be included with the audio streams in spatialization and mixing"? In these requirements: ---------------------------------------------------------------- Requirements related to audio processing ---------------------------------------------------------------- REQ-ID DESCRIPTION ---------------------------------------------------------------- F27 The browser must be able to apply spatialization effects when playing audio streams. ---------------------------------------------------------------- F28 The browser must be able to measure the voice activity level in audio streams. ---------------------------------------------------------------- F29 The browser must be able to change the voice activity level in audio streams. ---------------------------------------------------------------- F30 The browser must be able to process and mix sound objects (media that is retrieved from another source than the established media stream(s) with the peer(s) with audio streams. ---------------------------------------------------------------- F27 says "when playing". The other requirements don't. Is it obvious to everyone but me whether F28 and F29 apply to a browser sending audio, a browser receiving audio, or both?
Thanks for addressing my DISCUSS. The requirements listed in 3.3.7.2 are incorrect. First, F17 does not derive from the use case described in 3.3.7.1. Second, the text listed for F22 is not the appropriate text. To be consistent with how F22 is used in the rest of the document, it should say: "The browser should be able to take advantage of available capabilities (supplied by network nodes) to prioritize voice, video and data appropriately."
draft-ietf-radext-dtls
Thanks to the authors for the best and most concise statement of why "use IPsec" is pretty much never the answer for applications: "The requirement that [application] traffic be encrypted and/or authenticated is implicit in the network configuration, and cannot be enforced by the [application]."
Again, thanks for the good description of the experimental nature of this and the implementation info. - Would it not be feasible to require a PFS ciphersuite? Even that'd be a tricky MUST for current implementations, it'd be a good RECOMMENDATION. (Since server private key leakage is probably reasonably likely here over the longer term in a large deployment.) One option might be to note the UTA WG and say that its generic recommendations for TLS ciphersuites ought be tracked by implementers. A standards-track version later can probably fix this though, but good to note that this is a changing part of the (D)TLS landscape. - Are you or are you not requiring TLS client auth be implemented? I think you are but it'd be good to say more clearly that it MUST be implemented, perhaps esp. for client proxies. - If TLS client-auth is used (whether cert based or PSK) and you have a client-proxy, then I guess the server ought have a mapping from the TLS client id to the various RADIUS client identifiers (NAS-Identifier?) that are allowed use that proxy. Otherwise, the server is depending maybe too much on the proxy implementation to enforce authorization. - I'd recommend that (at some point) you think about DANE for this, it might work well. For now, maybe simply note it as a possible future option. - Given Heartbleed, I think you could maybe say some more about the use of DTLS heartbeat messages, e.g. to say that the PMTUD stuff SHOULD be <4096 bytes or something. Would that be useful? (It might not, if libraries don't provide a way to control it, but could be worth noting, and heartbleed probably is worth a note;-)
I've not had a chance to give a proper review to this document, so I will not take a formal ballot position (which doesn't have any effect for an Experimental document), but I want to echo Brian's comment and thank you for your well stated experimental description and implementation summary. We don't see enough of these in the IETF, and this will be a great example for future experimental work.
In Section 8, you change the contact person for the port registration to "IETF Chair". Probably better to use "Network Management Area Director", or something like that. Not a big deal either way, though.
I do have some comments. Please consider them along with any other comments you receive. 1. Introduction Another benefit is that RADIUS over DTLS continues to be a User Datagram Protocol (UDP) based protocol. The change from RADIUS/UDP is largely only to add TLS support. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Is this "largely" or "only"? Is this to add TLS support, or DTLS? This specification does not, however, solve all of the problems associated with RADIUS/UDP. The DTLS protocol does not add reliable or in-order transport to RADIUS. DTLS also does not support fragmentation of application-layer messages, or of the DTLS messages themselves. This specification therefore shares with traditional RADIUS the issues of order, reliability, and fragmentation. These issues are dealt with in RADIUS/TCP [RFC6613] and RADIUS/TLS [RFC6614]. Is the last sentence saying "if in-order reliable delivery of large RADIUS messages matters, you won't get that with RADIUS DTLS"? 1.3. Document Status RADIUS/DTLS allows manual distribution of long-term proofs of peer identity as well (by using TLS-PSK ciphersuites, or identifying clients by a certificate fingerprint), but as a new feature enables use of X.509 certificates in a PKIX infrastructure. I couldn't parse this sentence. I think the problem is close to "but as", but I'm guessing. 4. Client Behavior Clients may implement "pools" of servers for fail-over or load- balancing. These pools SHOULD NOT mix RADIUS/UDP and RADIUS/DTLS servers. I lack understanding why this is a SHOULD NOT. Is this biddown attack territory? If so, I'm more curious than usual ... 10. Security Considerations For systems which perform protocol-based firewalling and/or filtering, it is RECOMMENDED that they be configured to permit only DTLS over the RADIUS/DTLS port. Where deep packet inspection is possible, there should be further restrictions to allow only RADIUS packets inside of the DTLS session. Is there an obvious way to know whether deep packet inspection is possible? 10.5. Network Address Translation As a result, RADIUS/UDP clients SHOULD NOT be located behind a NAT ^^^^^^^^^^ I lack understanding how this could be a SHOULD NOT, given that NATs are translating the IP addresses used for security, as the previous paragraphs explain. Why isn't it MUST NOT? The next sentence goes to MUST. gateway. If clients are located behind a NAT gateway, then a secure transport such as DTLS MUST be used. As discussed below, a method for uniquely identifying each client MUST be used.
Completely non-blocking comments... 1. I found the information contained in section 1.3 interesting and potentially quite beneficial. By describing what aspects of the specification need assessment during experimentation, this section not only guides implementers/operators/users but also future IETF participants who would need to determine the spec's viability to move to the standards track. 2. Thanks for section 9. Knowing who has done some implementation work is quite useful.
draft-ietf-ippm-2330-update
Robert Sparks made some editorial suggestions in his Gen-ART review: --- Introduction, 3rd paragraph: What are the "proposed extensions"? Is this sentence trying to say "There are proposed extensions to allow methodologies to fulfill the continuity requirement stated in section 6.2, but it is impossible to guarantee that they can do so?" Bullet 2 in block 1. of section 3: The first sentence is a fragment, and is confusing. Should this bullet read "Payload content optimization (compression or format conversion) in intermediate segments breaks the convention of payload correspondence when correlating measurements are made at different points in a path."? (That is, delete ". This" and change "made"->"are made".) There are inconsistent styles used in the subsections of section 4 that cause the main points to be a little hard to pull out of the text: * in 4.1, you quote the new definition. Visually, that implies you're quoting another source, like you do above it for the old definition. I suggest doing something else to set this apart from the rest of the text - perhaps an indented block? * Whatever you do there, consider doing the same in the other sections. Highlight "we deprecate continuity" in 4.2, for example. * 4.4's point seems buried. Would it be correct to say (and would it help highlight the point): "Conservative measurements in these environments may not be possible."? Consider changing the heading text for 4.1 to 4.5 to highlight the change or observation you're making. That would help drive the point of the document in the ToC. Something like this (I'm sure I've blown the capitalization). 4.1. Revised Definition Of Repeatability 4.2. Continuity is not an Appropriate Alternative Criterion 4.3. Metrics Should be Actionable 4.4. It May Not be Possible to be Conservative 4.5. Spatial and Temporal Composition May Bias Sampling 4.6. Truncate the Tails of Poisson Deistrubutions In the conclusion, break the last (very long) sentence out into its own paragraph.
Section 3.1.2: "This payload content could be either generated by a random device or by using part of a compressed file (e.g., a part of a ZIP compressed archive)." Not sure what is meant by a random device. Surely the same device originally emitting the test traffic could emit traffic less likely to be compressed? I was also surprised that this section does not discuss the rise in transport layer encryption, which I would expect to counteract the push towards in-network optimization in some cases.
draft-ietf-opsec-vpn-leakages
I just can't sign on to another document that recommends turning off IPv6 as a mitigation strategy. Please take that out.
Many thanks for engaging with Martin Vigoureux who tells me that all of his Routing Dir issues have now been resolved.
- section 2: The terminology section is not very clear as to how TLS-based tunnels are not the same as TLS VPN portals. And the slides referenced don't really seem to cover TLS tunnels for general IP traffic but rather TLS tunnels from a browser to an entreprise, presumably with the tunnelled traffic being HTTP/XHR. I think some additional wording should clear this up. I saw that this was discussed as part of the secdir review but I don't think the text is quite there yet. Maybe, saying "IPsec VPNs and VPNs that use TLS for key manamgent, but that also tunnel general IP" is a way to cover both IPsec and e.g. OpenVPN? - section 3: routing also "ties together" different versions of IP, re-phrasing that might be better. - section 4: the "underlying problem" is that the VPN s/w doesn't support v6, not that DNS has both A and AAAA RRs. - (niggly nit) Another "turn off v6" recommendation! (sigh) - Don't VPNs also "leak" other traffic, e.g. DHCP when the non-VPN lease needs renewing or already opened connections? And if a VPN client is badly configured then lots more could leak too. Why not note these?
I'd like to see a new version with the edit that Russ Housley suggested in his Gen-ART review.
I have moved my technical concerns on the document to the comments section, as I expect that I will be moving to Abstain on this document; whatever the outcome, I can't in good conscience recommend this document. But I want to DISCUSS this one last time on this telechat for two reasons: - I have read over the OPSEC archive discussion of this document since IESG review, with the WG being specifically pressed to address some of the comments. The response was not impressive. - It seems to me that from Benoit's comments, he is likely an abstention as well. Even though his change in ballot would not make a formal difference to the outcome (it is an Informational document, and therefore a single "Yes" is sufficient), perhaps 4 abstentions would give Joel pause. (Perhaps not. ;-) ) If this is a substantive problem with VPN deployments, I would have expected OPSEC to be pushing this as a BCP with specific instructions on how to address the problem and harsh words for broken implementations. But I don't see that motivation or urgency. So I continue to doubt the worth of this document, and I think its continued implication that disabling v6 is a reasonable path forward is a shame. But short of a change of heart of the WG or the rest of the IESG, I will not stand alone in front of this document past this telechat.
The scenarios and the solutions in this document strike me as somewhat bogus, and I'd like to hear if the WG had any data on these usage scenarios: - Most VPN installations I know of secure traffic to particular addresses by employing the VPN to do two things: a) Encrypt the traffic, and b) Get through a firewall that prevents traffic not coming through the VPN to never get to the hosts. In that case, if a non-v6 supporting VPN is used, the v6 traffic never even begins, because the traffic simply can't reach the v6 endpoints behind the firewall. Are most VPNs not employed in the way that I describe? - The document seems to assume that VPNs are somehow used to generically encrypt traffic that is not encrypted. But the vulnerability here seems to be the use of the VPN for such purposes. To secure traffic to a service, what you want to do is have the application secure the stream of data in some way (e.g., TLS), not have applications that blindly send clear traffic and then hope it goes through the VPN. Are VPNs actually being used to do this generic blind encryption? Are most of the instances of this not also instances of the firewalled scenario I asked about above? - The document refers to v4 and v6 being "'tied' together by the DNS". However, most VPNs I am aware of actually force the use of a particular DNS server on the user of the VPN. In those cases, if the VPN is v4 only, and that DNS is returning v6 addresses, it seems like the appropriate mitigation is to stop returning v6 addresses through that VPN-configured DNS server, not to disable all v6 interfaces. Are most VPNs not using their own configured DNS? - The mitigations in 7.1 never say, "Fix the VPN software to support v6", nor does it say, "stop advertising v6 addresses for things that you expect to go through the VPN". Those seems like much more sensible mitigations. The choices in the document are "use v6-enabled VPNs" or "don't use v6". Those seem like lousy choices. - It does seem clear that many of the problems described in this document are equally applicable to *any* VPN that allows split-tunneling, whether that VPN is allowing only v6 to be split (perhaps accidentally) or purposely allowing any sort of split. The document handwaves at this in section 2, but assumes non-split-tunnels in section 4: ...the IPv4 connectivity by, e.g. inserting an IPv4 default route that causes all IPv4 traffic to be sent over the VPN connection (as opposed to sending the traffic in the clear, employing the local router). and never really addresses in section 7 that split tunnels suffer the same problems. The analysis in this document seems very weak to me. I'm not a security guy, but the scenarios and mitigations described in this document don't seem truly representative of VPN usage. At the very least, the document never gives any data indicating that the scenarios are the real problem.
I like the fact that the leakage issue is well described. Thanks for that. However, Russ' GEN-ART review also resonates with me: I do not find this document very helpful. It can be summarized as: If IPv6 is not supported in your VPN software, then disable IPv6 support in all network interfaces before you try to use it. I do not know why the OPSEC WG thinks that this message is worthy of an RFC. This is also in line with Dan Romascanu's OPS DIR review at http://www.ietf.org/mail-archive/web/ops-dir/current/msg00050.html. Please address Dan's review. As others have said, the resolution should be: fix the VPN software to support IPv6 in a dual-stacked host/network.
Thank you for adding the scope limitations in the terminology section from my SecDir review. This does help to better narrow and explain the applicability of this draft, it is a definite improvement. To address Stephen's comment on section 2, you can go back to the SecDir review discussion where detailed explanations were provided by myself, Paul Hoffman, and Steve Kent on the types of VPN and why this is limited to VPN tunnels. The terminology is specific for TLS vs. IPsec tunnels. Although several implementations have been corrected as a result of this draft, I also do not think there is a big need for this to become an RFC as we are not aware of any outstanding implementations that need to be fixed, correct? Is section 4 still true? I thought from previous exchanges on this draft that the problems in the VPN agents that had this issue were resolved as a result of this draft? I agree with Pete on the push back related to the DNS statements in section 4. The draft states the issue is caused by DNS, but I suspect it is actually routing and the VPN software knowing how to handle IPv6 addresses. If you just address this at a DNS level where IPv4 addresses are returned, you'll wind up with issues when IP addresses only are used and the same problem would continue to occur.
-- Section 2 -- When employing the term VPN (or its acronym, "VPN") Eh? I guess the first was meant to be spelt out.
I found this document to be pretty clear for the non-expert reader. I did have a couple of comments that you might want to consider, along with any other comments you receive. In this text: 7.1. Fixing VPN client software Finally, we note that if (eventually) IPv6-only VPN implementations become available, they should consider similar issues that would ^^^^ arise if they do nothing about the IPv4 traffic. ^^^^ I'm reading "they" as "IPv6-only VPN implementations", but I'm not sure that's what you intended. I might also have guessed "administrators", if I was guessing. If you meant something else, could you consider using a noun, and not a pronoun? In this text: 9. Security Considerations Possible ways to mitigate this problem include fixing the VPN client software, or disabling IPv6 connectivity on all network interfaces when the previous option is not feasible. These are the recommendations the document is making, are they not? I would have thought what this section is asking for, is what security considerations might arise from following those recommendations. Finally, Stephen was asking about what else might leak, which is an interesting question, but I'm wondering if that's something different - he's talking about "leaking" (say) a small amount of DHCP traffic that someone could eavesdrop and learn something the eavesdropper shouldn't know, while IIUC, this draft is mostly about 'leaking" potentially a much larger and potentially more revealing amount of traffic (like, all of the email I'm downloading from my mail server), and (in these two examples) potentially "leaking" it over a much larger distance (network-wise). Is there a better term for what this document is describing? "No", or "no, that's actually the right term of art on both cases", would be a fine answer ...
What Pete said... This is another example of giving guidance to disable IPv6 rather than guidance on how to address the limitations causing the perceived problem. I would have liked to have seen, for example, guidance on what DNS record types should be available via a VPN connection running over IPv4.