IESG Narrative Minutes
Narrative Minutes of the IESG Teleconference on 2014-06-12. 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: Pete
2. Protocol Actions
2.1 WG Submissions
2.1.1 New Items
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
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
3.4.2 Returning Items
1203 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
4.2.2 Proposed for Approval
5. IAB News We can use
6. Management Issues
7. Agenda Working Group News
1239 EDT Adjourned
(at 2014-06-12 07:30:17 PDT)
- general: This draft has some acronyms that conflict with other ITEF things, specifically TLS and MTU. Those might be worth emphasising but I expect that you'd rather not, which is fine. I also found this a bit of a hard read, mostly due to a lack of background, so some of my comments may be off-base. - MTU-s - how "multi" tenant? Are there mutually mistrusting customers using the same node/host here? - Even with LDP authentication, isn't there the potential that an authenticated actor DoS'es others by causing their MAC addresses to be flushed? That seems to imply some form of authorization (e.g. mapping authenticated identities to MAC addresses) is required - is that defined somewhere else? If not, why doesn't it need to be defined here? If it does need to be defined here, you probably only need to say that such a mapping MUST be maintained. - section 3: I can't really parse this "This is accomplished by sending an LDP Address Withdraw Message from the PE that is no longer connected to the MTU-s with the primary PW, with the list of MAC addresses to be removed to all other PEs over the corresponding LDP sessions [RFC4762]." Could you break it up to make it clearer?
Thanks for fixing my Discuss
The risk noted in Stephen's DISCUSS is worth considering. I suspect the answer lies in how a BGP speaker handles a dropped session. Everything is fine if either it discards any incomplete refresh or it discards all BGP state associated with the session. In the former case, this document would need to specify the behavior; in the latter, assuming the behavior is documented elsewhere, a citation and note would be helpful.
- section 4: I don't get why you need to say that stuff "MAY be logged" - is that really needed? Are there real conventions for what to not log with BGP? If so, I could understand these statements, but absent such, I don't see you need 'em. Equally, there's no problem saying that, it just jumped out as an odd thing to say.
This should be very easy to resolve, could you add in a reference to the appropriate Security Considerations section of an existing RFC that covers the list of known security considerations? It would be good to know exactly where to look as opposed to just saying no more are added.
I have a couple of tiny nits that should be pretty easy to address. This would read easier if the acronyms were handled a little differently, could this be changed from: 0 - Normal route refresh request [RFC2918] with/without ORF [RFC5291] 1 - Demarcation of the beginning of a route refresh operation. Also known as a "BoRR message" or just a "BoRR". 2 - Demarcation of the ending of a route refresh operation. Also known as a "EoRR message" or just a "EoRR". To: 0 - Normal route refresh request [RFC2918] with/without ORF [RFC5291] 1 - Demarcation of the beginning of a route refresh (BoRR) operation. Also known as a "BoRR message" or just a "BoRR". 2 - Demarcation of the ending of a route refresh operation (EoRR). Also known as a "EoRR message" or just a "EoRR". Maybe it's just me, but I had to read it twice without that, if you change this, you could drop the "or just a "BoRR"" and "or just a "EoRR"" clauses. Section 4, Could you expand on <AFI, SAFI>? Looks like it is in Section 3 of RFC5291, I had to look them up and I am sure from how it is described that they are really well-known acronyms.
I just have a couple of minor, non-blocking comments that I'd like you to please consider: -- Section 1 -- It is sometimes necessary to perform routing consistency validations such as checking for possible missing withdraws between BGP speakers "Withdraw" is not a noun; the noun should be either "withdrawal" or "withdrawn route". Both are consistent with usage in RFC 4271. -- Section 4 -- A BGP speaker that supports the message subtypes for the ROUTE- REFRESH message and the related procedures SHOULD advertise the "Enhanced Route Refresh Capability". Why "SHOULD"? Under what conditions might such a BGP speaker not advertise it? I think what you really mean here doesn't need 2119 key words at all: change "SHOULD advertise" to "advertises".
I support Adrian's DISCUSS points.
Oh boy, passive voice. (no this doesn't need to be fixed)
Adrian raised this as a nit, but it's really a DISCUSS: a conforming implementation of this specification could perfectly well accept an unauthenticated hello after it's accepted an authenticated hello, because there's no requirements language forbidding this behavior. One would hope that implementors would be smart and not do this, but given that this is a standard, it SHOULD be mentioned explicitly. :)
I'm also curious about Brian's "Is it worth mentioning why DTLS is not sufficient for this UDP-based protocol?" comment, but whatever you decide in conversations with him will be fine with me.
IANA's questions have been addressed through several revisions and clarifications. This document is ready to progress. --- Please fix the nit raised by Joel Halpern in his Rtg Dir review... The one nit is that I could not find the text indicating that if a receiver receives an unauthenticated LDP Hello packet, and is expecting authentication to be used (either always, or with the source the packet claims to be from) then the hello packet should be silently discarded.
I agree with Ted's DISCUSS in spirit, even if I disagree with it as stated. What needs to be clear here is that the LSR receiving Hello messages needs to have a policy for each neighbor as to whether it requires authentication or does not. If it is configured to require authentication, it MUST NOT accept unauthenticated Hello messages. (Ted's message implies that this policy should be configured based on receipt of authenticated messages, which is a terrible idea.)
Many thanks to the authors/chairs and the secdir reviewer (Yaron Sheffer) for working hard to significantly improve this document (from the security weeny point of view:-) abstract: this is really defining a way to use HMAC (with SHA) and not just SHA, it'd be better to put it that way in the abstract. intro says: "The LSRs could be configured to only accept Hello messages from specific peers when authentication is in use." Isn't "could" a little understated there? Presumably you would only ever use this if you have some list of (keys/identifiers) and you don't want messages from outside that set to affect that set of LDPs? I'm not suggesting you add a MUST (unless you want to) but more that you say that this mechanism only makes sense if you are in fact configured to "only accept..." 2.2: The last para here calls for extending the lifetime of the "last" key indefinitely. That's probably justifiable for operational reasons, but would be considered "odd" for crypto devs perhaps. And there could be issues with using a key a really really large number of times even for HMAC, I'd have to go ask someone (that kind of formula is not in my brain-buffer:-) and its probably mainly theoretical here but a crypto API just might insist on that in some cases causing an interesting failure case. Anyway, I think it might be worth making this last para a subsection of its own so its more likely to be noticed by developers. And you might want to consider what happens if a crypto API insists that the application can no longer use that key because its been used too many times. section 5: I think that the AuthTag having the source IP address as input is what prevents reflection attacks. Is that correct? If so, then I think that would be worth calling out specifically either here or in the security considerations. (And whenever we get to the point of running LDP via NATs, then this AuthTag will need to change, but that, I assume, is ok for now.) 6.1: Why the last sentence? section 7: not asking for this to go into the doc (unless you want) but I'd be interested in knowing if there are any interesting residual threats related to the fact that we're not providing confidentiality here. Its ok if you don't want to answer this bit btw, I'm just curious.
Thank you for addressing the SecDir review. I support Stephen's comments and will watch the responses. I don't have anything else to add.
I have two simple technical concerns. 1) Hello messages are sent out per interface with the transport address specified either implicitly or explicitly. Different transport addresses can be used for different label spaces or to create different sessions. Can the draft clearly specify that the Cryptographic Sequence Number is a single space per LSR regardless of the used transport address? 2) Given that an LDP session is frequently identified by the transport address, I'm not sure that a receiver can reliably tell "the same neighbor" if that neighbor is using different transport addresses (possibly as the source address as well as via the TLV). The draft specifies: " If the cryptographic sequence number in the LDP packet is less than or equal to the last sequence number received from the same neighbor, the LDP message MUST be discarded, and an error event SHOULD be logged." Can you please clarify that "same neighbor" means "same source IP address", if that is the intent?
I also support Ted's concerns about when an unauthenticated hello packet should be accepted (see email thread).
The definition of the Length field in section 2.3 is nebulous. Does it include the 96 bits of fixed-length fields or just the variable length Authentication Data. It is unclear since the definition says it is the length of the "value field". Is it worth mentioning why DTLS is not sufficient for this UDP-based protocol?
Section 1: "Of the above, implementations MUST include support for at least HMAC-SHA-256 and SHOULD include support for HMAC-SHA-1 and MAY include support for either of HMAC-SHA-384 or HMAC-SHA-512." This makes it sound as if HMAC-SHA-384 and HMAC-SHA-512 support are mutually exclusive. I think the phrasing in Section 3 is better and should be repeated here (or, in any event, the two sections should say the same thing): "Of the above, implementations of this specification MUST include support for at least HMAC-SHA-256 and SHOULD include support for HMAC-SHA-1 and MAY also include support for HMAC-SHA-384 and HMAC- SHA-512." Section 2.2: "This is a 32-bit unsigned integer used to uniquely identify an LDP SA between two LDP peers, as manually configured by the network operator (or, in the future, possibly by some key management protocol specified by the IETF)." It would help to clarify whether you mean (1) a key management protocol that does not already exist may be defined in the future and used for this purpose, or (2) in the future SA IDs may be configured using a key management protocol that already exists. "In order to achieve smooth key transition, KeyStartAccept SHOULD be less than KeyStartGenerate and KeyStopGenerate SHOULD be less than KeyStopAccept." What are the conditions under which these SHOULDs might be violated?
Thanks for including the explicit and clear statement on backwards compatibility. --- A note for the responsible AD: This document creates a registry that needs a designated expert. I suggest you add an item to the Management Items part of the agenda to assign the experts.
Quoting Melinda, part of her OPS-DIR review: This document introduces new IS-IS flooding scope PDUs, and defines new TLVs and sub-TLVs with 16-bit type and length fields. I feel this document is ready for publication, with a note that RFC 4444 (the IS-IS MIB) should probably be updated at some point in the future. I don't believe an extra note is needed in the draft, in light of http://www.ietf.org/iesg/statement/writable-mib-module.html The only one I could think of is: "The old RFC4444 MIB module doesn't support this new functionality", which is so obvious than it doesn't add any value.
Thanks for Discussing with me. I like your proposed text, which is "When deploying support for a new flooding scope correct operation therefore requires both FS PDUs and the new scope be supported by all routers in the flooding domain of the new scope."
Thank you for producing this document. If I was more familiar with the details, I'd have balloted "yes".
I will simply ask this as a question; I have no intention of DISCUSSing it. If the SEC ADs are interested, they are in a much better position to DISCUSS: Given that there's confidentiality/integrity protection available at the application layer, I was left to wonder why 3GPP wanted to do it at the transport layer. I'm worried that the reason they want to do this is in order to more easily *violate* confidentiality: Doing it at the transport layer means that intermediaries can peek at the contents of the FAX, whereas doing it at the application layer prevents everybody but the end users from being able to peek. Is that what's going on here? If so, and if this is considered a reasonable thing to want to do, that should probably be called out as a potential vulnerability in the security considerations (or perhaps a new privacy considerations) section. Sorry for thinking nefarious thoughts, but I've got to ask.
Apologies for the brief review, (I'm a bit short of time;-) but I have the following questions: (1) Don't you need to mandate sha-256 as MTI for the rfc4572 fingerprint ? (2) What DTLS ciphersuites are MTI? (MTI = mandatory to implement, just in case:-)
Thanks to Pete for raising questions on the introduction. From the discussion so far, I think this will be easy to resolve, but would like to make sure that happens for clarity in the document, so I am using this Discuss as a placeholder for that. From Pete's comment, the introduction is not clear as to why this solution is needed. When you dig deeper, (and it takes a bit of researching), you can see that a solution is needed for secure IP transport. I'd like to see the introduction expanded to better explain the problem and existing gap. The transition to IP from telephony protocols (T.30) makes sense as a major motivation. An issue that comes up for someone new to this is that the T.30 document explains the solution as an application layer approach that applies to any protocol, so there must be a gap here that the experts are aware of and can explain. With the current text on existing solutions, the reader has to know a lot more to understand T.38 RTP and UDPTL. The listed solutions talk about T.30 and RTP, so unless the reader knows they are competing solutions (doesn't say that in the introduction, just puts them both in the T.38 document for reference), they won't know why this doesn't fit the bill. If you start searching around, RFC4612 section 3 must have been written before UDPTL tool off and gained the market share. I am including all of this so you might see where someone new to this work would need additional information in the introduction to better set the understanding for the reader. I had suspected when I read it yesterday that the main reason was that traditional faxing is going away and integration with applications is needed for how people work, but that is not said anywhere. Regulatory requirements also drive this with the need for transport encryption (no need to name the many ones as they will change and evolve).
UPDATE: I asked Dave Crocker for a review, as he chaired the fax working group, way back when. One comment that he made, which I agree with and want to pass on, is this: << When the technical details of a reference are so fundamental to a new specification, I prefer the citation to it to be as precise as possible, to save the reader from having to do searching. Hence I suggest that the initial reference to UDPTL should explicitly cite "Section 9" of the t38.2010 doc. >> ----- Christer has responded to all my earlier comments; I leave the responses here for the record. Thanks! -- Section 4.2 -- The offerer SHOULD assign the SDP "setup" attribute with a value of "actpass". Alternatively, the offerer MAY assign the SDP "setup" attribute with a value of "active" or "passive". The offerer MUST NOT assign an SDP "setup" attribute with a "holdconn" value. Standard SHOULD/MAY problem: MAY is not an alternative to SHOULD; MAY is entirely optional. In order to resolve this, let me first ask *why* the offerer SHOULD set "setup" to "actpass", under what conditions might the offerer need to use "active" or "passive" instead, and what are the consequences of doing that? ------------------------- RESPONSE: Setting the value to "actpass" allows the terminating endpoint to determine the TLS role, ie which endpoint will send ClientHello. "active" or "passive" is used if the offerer, for whatever reason, insists on being either the sender (TLS client) or receiver (TLS server) of the ClientHello. In order to solve the SHOULD/MAY problem, I suggest the following modified text: The offerer SHOULD assign the SDP "setup" attribute with a value of "actpass", unless it insists on being either the sender or receiver of the DTLS ClientHello message, in which case it can use either a value of "active" (sender of ClientHello) or "passive" (receiver of ClientHello). --------------------------------------------------- -- Section 5.2.2 -- The UA MUST demultiplex packets arriving on the IP address and port associated with the DTLS association, e.g. as follows: I'm not sure what the "e.g. as follows" is saying. Are the two bullets meant to be one example how how one might demultiplex the packets, and there are also other ways one might do it? Are the two bullets a suggested way, or just an example? Or is there some other sense that I'm not seeing? ------------------------- RESPONSE: The idea is to mandate support of the mechanism described in the document, but to not prevent usage of alternative future mechanisms. I agree that the current text is a little confusing, so I suggest the following modified text: "The UA MUST support the following mechanism for demultiplexing packets arriving on the IP address and port associated with the DTLS association:" o If the value of the first byte of the packet is 0 or 1, then the packet is STUN. o If the value of the first byte of the packet is between 20 and 63 (inclusive), the packet is DTLS." --------------------------------------------------- Very, very small, tiny point, which you can completely ignore if you like: "SHALL" and "MUST" mean exactly the same thing, and I always find it preferable to use one or the other, consistently. You mostly use "MUST", but in Sections 3, 5.1, and 5.2.2 you have one instance each of "SHALL". I mildly, mildly suggest that you change those three to "MUST", to be consistent. ------------------------- RESPONSE: I agree with you, and I am happy to replace SHALL with MUST. --------------------------------------------------- -- Section 4.4 -- When the offerer receives an SDP answer and, if the offerer ends up being active it MUST initiate a DTLS handshake by sending a DTLS ClientHello message on the negotiated media stream, towards the IP address and port of the answerer. That reads oddly to me, mostly, I think, because of the "and, if" bit. Maybe you just need to delete the comma and the "if". Alternatively, you could delete "and". ------------------------- RESPONSE: I suggest to remove "and". "When the offerer receives an SDP answer, if the offerer ends up being active it MUST initiate a DTLS handshake by sending a DTLS ClientHello message on the negotiated media stream, towards the IP address and port of the answerer." --------------------------------------------------- -- Section 5.3 -- After the DTLS handshake caused by rekeying has completed, because of possible packet reordering on the wire, packets protected by the previous set of keys can arrive. That sentence seems awkward because things come in an odd order -- kind of backward. May I suggest this?: NEW During rekeying, packets protected by the previous set of keys can arrive after the DTLS handshake caused by rekeying has completed, because packets can be reordered on the wire. END ------------------------- RESPONSE: Looks good. I'll update as suggested. --------------------------------------------------- -- Section 6 -- The standard DTLS strategy for authenticating the communicating parties is to give the server (and optionally the client) a PKIX [RFC5280] certificate. The client then verifies the certificate and checks that the name in the certificate matches the server's domain name. This works because there are a relatively small number of servers with well-defined names; a situation that does not usually occur in the VoIP context. I don't follow the last sentence. I don't understand why there are relatively few servers that have well defined names. I don't see why that's important with respect to how authentication by cert validation works. And I don't get how this relates to VoIP. Can you explain, please? ------------------------- RESPONSE: We borrowed the text from RFC 5763. However, I agree that the VoIP text is confusing, and suggest the following modified text: "The standard DTLS strategy for authenticating the communicating parties is to give the server (and optionally the client) a PKIX [RFC5280] certificate. The client then verifies the certificate and checks that the name in the certificate matches the server's domain name. This works because there are a relatively small number of servers and the cost for issuing and deploying PKIX certificates can be justified. Issuing and deploying PKIX certificates to all clients is not realistic in most deployment scenarios." ---------------------------------------------------
Ah, the glories of getting a late start on telechat reading. I would have balloted Discuss on approximately Stephen's point, but it's already being robustly discussed among people who understand the details better than I do, and seems close to converging. :D
My Discuss contains two rather minor points that need to be ironed out to make sure that the document is unambiguous. --- In two places in the document you have The definition of any Realm-Local scope for a particular network technology should be published in an RFC. For example, such a scope definition would be appropriate for publication in an 'IPv6- over-foo' RFC. Any RFCs that include the definition of a Realm-Local scope will be listed in this registry. I think this is giving specific instructions about a subregistry that needs to be maintained. That is, a registry of real-Local scopes. Could you please set out for IANA exactly what information you want them to record in that subregistry. --- The update to RFC 4007 puzzles me. You would have the new text read... o The boundaries of zones of a scope are defined by the IPv6 addressing architecture [RFC4291] and updated by this document. "This document" would not be RFC 4007, I suspect despite the quoted text being intended as a substitution in RFC 4007.
Pardon my multicast ignorance (I only used smcroute for the 1st time recently:-) but what happens if a router in the group supports two different technologies on different interfaces, each of which defines scop=3 to be something local(-ish) - do the packets get forwarded between technologies or not? If the answer to the above is "yes," then I think there's a security consideration to be stated here, which is that scop=3 does not mean that packets are limited to being seen by nodes running a specific technology but may go further via a router. That could be unexpected enough to be worth stating. If the answer is "no" then I think you need to change the draft to make that clearer, if you want people like me to understand that. Or maybe its just a dumb question:-)
I'm curious to see the response on Stephen's question. Also, the referenced security consideration sections don't talk about the global scope and any risk related to not having a boundary. Some text on that could be helpful or perhaps an explanation so I know why it is not needed would be helpful.
1. Did you mean to change the text for scop=1 in the table, from "Interface-Local scope" to just "Interface"? I don't think so. 2. In Section 3 you say this: Section 5 gives the definition of scop 3 for IEEE 802.15.4 [IEEE802.15.4] networks. ...but then Section 4 immediately talks about Section 5 of RFC 4007. Just to make sure no one misunderstands, maybe Section 3 should say, "Section 5, below, gives...", yes? 3. I understand you're about to submit a revised I-D that clarifies this from the IANA Considerations: The registry will have a note associated with scope 3 listing all RFCs that define Realm-Local scoping rules that use scope 3. I await that update, and might comment further...
Agree with Adrian's discuss and Stephen's comments.
Just a Comment to track the editorial nits raised by Christer Holmberg in his GenArt review
The Requirements section discusses the need for confidentiality, but this is not mentioned in the Security Considerations section which just covers DoS attacks primarily. Since confidentiality is a requirement, can you elaborate on how the solution covers this? I see the discussion in Section 8 on "protection", but that doesn't seem to cover security protections when I read into the references on what seems to be the scope of the term "protection' used in this draft. From Section 5: It is also important that the solution can preserve confidentiality across domains, which is required when domains are managed by different Service Providers via Path-Key mechanism [RFC5520].
I like the proposed experiment (and that it is an experiment), and I think this document's well written. Thanks for discussing the point below with me. The result of the discussion is that the working group considers the number of bits to be sufficient to allocate this one, and can always allocate an experimental bit later if this seems to become common. Former DISCUSS point, resolved: I have one simple point of DISCUSSion about the code point assignment in the RP Object Flag Field registry. I see from the archive that it does appear to have been discussed in the working group -- there's an unfortunate lack of any record of discussion after working group adoption (though much discussion before), but the registration request was removed in -04, and then put back in in -06 after Adrian's review. Here's my question: The RP Object Flag Field registry only has 18 bits left, and you aim to take one of them for this experiment, for which the shepherd writeup notes that "Implementation beyond prototype is not clear." Do you really want to take up a permanent bit just for this, even if the experiment turns out to fail (or to be unimplemented or undeployed)? Might it be better to allocate a bit for experimental use, and to use that for this experiment, allowing use of that same bit for other experiments as well? It would mean that if this one does take off, you'd have to switch later to a non-experimental bit. Or are you really quite sure that this *will* take off, and you'll need the bit for sure? (Or, alternatively, are you quite sure that 18 bits is well and truly enough, and you don't care?)
The WG chair and Shepherd need to show IETF consensus on the draft. Many of the comments made in IETF last call were addressed and others may be duplicating what was discussed in the WG - but that needs to be clearly articulated in the Shepherd's report. Matthew is updating the Shepherd's report to indicate how the IETF last call input was considered.
Thanks for this document. I know it represents a lot of effort. The document is very clear and a good read. I have just a few minor points for you to consider as you progress the document. ---- Tiny ambiguity... Virtual Network (VN): A VN is a logical abstraction of a physical network that provides L2 or L3 network services to a set of Tenant Systems. It is the VN or the physical network that provides the L2 or L3 services? --- You have... The Underlay Network does not need to be aware that it is carrying NVO3 packets. I wondered whether you wanted to make a stronger statement here. We usually have a stronger separation of overlay and underlay such that The Underlay Network is not aware that it is carrying NVO3 packets. --- Possibly "NIC card" is tautology. --- Format of Figure 3 is a bit messed up --- The use of "seamless" in Section 3.3 seems a bit or an overstatement or perhaps just under-defined. Given the text that follows, I would just delete "in a seamless manner" from the first paragraph.
Thanks for Section 4.2 and especially 4.2.4 and 4.2.6. Good to have the discussions about the challenges!
This is combined feedback from the OPS DIR review (Thanks Al Morton) and my own review. I like the document and in particular section 4 about "Key aspects of overlay networks" - Thanks for section 2.4. Operational Management Considerations, but I share Al Morton's views (OPS-DIR review) on this section ... As far as the IP underlay is concerned, existing IP OAM facilities are used. So, a clear mapping between overlay and underlay addresses is needed by the person or entity directing OAM activities, right? It appears section 188.8.131.52 discusses this to some degree. Section 3.3 on VM Mobility adds to the complexity of performing meaningful OAM. Maybe I expect too much from this document and this is/will be covered in draft-ashwood-nvo3-oam-requirements? . . . As far as configuration is concerned, the DC environment is driven by the need to bring new services up rapidly and is typically very dynamic specifically in the context of virtualized services. It is therefore critical to automate the configuration of NVO3 services. This last sentence sounds like a requirement, but automation does not appear to be addressed very extensively in the draft, except that VNI values are automatically generated by the egress NVE, and there are a few others. - 4.1. Pros & Cons The Cons and other issues raised in section 4 are potential pitfalls for operations, and this could be noted. In particular, sections 4.2.5 and 4.2.6 point to difficulties of VM placement and the lack of interaction between network layers when coordination is needed in critical areas. For example, with many specific examples provided in the previous sections, how do the authors recommend to provision bandwidth in the IP network for each, ideally performance-isolated, VNI? EDITORIAL: - ... to provide similar functions to a ToR. ... Another example is the case where the End Device is the Tenant System, and the NVE function can be implemented by the connected ToR ... ToR => ToR switch There are multiple instances of this. - Having figure 3 and section 3 would help readability. - Some more comments, more editorial, from Al Morton Although I don't request a change in terminology, I found the term "underlay" to be distracting as a non-indoctrinated reader. Further, Figure 3 doesn't identify the underlay network, but it depicts the L3 Network (IP underlay) above the "Overlay" network and therefore the figure is drawn upside-down. I think "foundation" would be a more easily understood term for some readers, but the Figure should identify the underlay network and be re-drawn for clarity, at least. Perhaps some of the difficulty with the underlay network concept is the alternate reference to either IP networks or L3 networks/ technologies: . . . In the case of NVO3, the underlay network is IP. ... Underlay nodes utilize L3 technologies to interconnect NVE nodes. These nodes perform forwarding based on outer L3 header information, It's hard to maintain clarity with numbered-layers in the face of overlays, underlays, tunneling, VPNs (but here L* is embedded in the names), etc., but can't solve the whole problem here.
The overview is very good for NVO3, but I think it could benefit from some additional information in the security considerations and would like to discuss that with a couple of concerns. 1. The Security Considerations section hint around the risk of breaking the intended isolation of tenants without ever stating that possibility in the first few sections that describe securing NVEs, NVAs, and management systems. The risks should be explained so that the reader, including developers and implementers, understand that breaking the designed tenant isolation is possible when security requirements and considerations are not met (or there are weaknesses/flaws in software). This may help to further motivate implementation of security requirements. 2. The framework describes both overlay and underlay networks. When responding to Alissa's discuss, I would like like to see the text address when encryption is needed with the associated risks for the overlay and underlay networks as well, the answers may be different for each. The security considerations section goes back and forth between the two right now without always calling out which it is referring to and this would be helpful. This is also the case for the unauthorized access descriptions in the security considerations section. I'm adding this as a second discuss to make sure we can work through some text to add and these considerations are included as I think they will be helpful to address what each means for both overlay and underlay networks (management/control data and tenant data).
I fully support Alissa's DISCUSS and comment. For the discuss, it would be helpful to see her questions addressed rather than just changing may to must. I agree with her list of questions and would like to see this further elaborated on in the draft. For her comment, it would be good to include the reference intended in the draft for opportunistic encryption to avoid confusion.
I note that the security ADs have not balloted on this document yet, so they may have better/different ideas about the two points below. Section 5: "When NVO3 data traverses untrusted networks, data encryption may be needed." As written, this is sort of a truism and seems a little weak. Under what circumstances would it be advisable to transfer NVO3 data unencrypted across untrusted networks? Seems like those need to be fleshed out here, or otherwise the recommendation should be for encryption to be used when sending data on untrusted networks.
Section 3.1.4: "When confidentiality is required, the use of opportunistic encryption can be used as a stateless tunneling solution." Since there is active debate about "opportunistic" terminology, just wanted to check if this is meant as "opportunistic encryption" in the RFC4322 sense, or something else (e.g., "opportunistic security" [http://tools.ietf.org/html/draft-kent-opportunistic-security-01][http://www.ietf.org/mail-archive/web/saag/current/msg04932.html]).
can you find something other than BUM?
I support Pete's DISCUSS.
I actually sort of agree with Pete that this would be better as PS. But I don't care enough to block the document.
You don't say (or I missed it while reading in a hurry;-) if a child can have the new key be the same as the old key. What happens if a child does that?
[Note to Stephen and probably Richard: Please avert your eyes. Reading this DISCUSS may damage your senses.] Why in heavens name is this document not being put forward for Proposed Standard? There is no explanation at all in the shepherd writeup (no dessert for the shepherd tonight), and the ballot writeup only says that there may be more than one way to do this, which doesn't preclude this being a Proposed Standard. This document defines a new RRType and defines how it gets used. That sounds like protocol to me. What gives?
Thanks for a very well written document, and for a good separation of normative and informative references. Version -14 addresses my minor comments and clarifies the IANA considerations -- thanks.
Section 1: 'This document is a compilation of two earlier drafts: draft-barwood- dnsop-ds-publish[I-D.ds-publish] and draft-wkumari-dnsop-ezkeyroll.' Does draft-wkumari-dnsop-ezkeyroll exist or was that supposed to be a reference to draft-kumari-ogud-dnsop-cds? Either way, a citation is needed. Section 2.2: 'After a Child DNS Operator first signs the zone, there is a need to interact with the Parent, for example via a delegation account interface, to "upload / paste-in the zone's DS information".' What is being quoted here?