IESG Narrative Minutes
Narrative Minutes of the IESG Teleconference on 2013-06-27. 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: Barry
1 Administrivia
Guests:
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
Telechat:
Telechat:
Telechat:
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
1219 EDT no break
4 Working Group Actions
4.1 WG Creation
4.1.1 Proposed for IETF Review
Telechat::
4.1.2 Proposed for Approval
Telechat::
4.2 WG Rechartering
4.2.1 Under evaluation for IETF Review
Telechat::
4.2.2 Proposed for Approval
1233 EDT break
1239 EDT back
Guests:
5. IAB News We can use
6. Management Issues
Telechat::
Telechat::
Telechat::
Telechat::
Telechat::
7. Agenda Working Group News
1414 EDT Adjourned
(at 2013-06-27 07:33:15 PDT)
draft-ietf-storm-iser
In 1.1, you seem to have a diction problem in Completion:
Completion is defined
as the process by the RDMA-Capable Protocol layer to inform
Do you mean "Completion is defined as the process by which the RDMA-Capable
Protocol layer informs"?
I assume that iSCSI control-type PDU and iSCSI data-type PDU are terms of art,
and that you can't change them, but these are horribly confusing terms to use.
If possible, it would be better to leave out the "-type" part of the name, and
use a name that makes clear that these are messages, and not pieces of hardware.
iSER-IRD - This variable represents the maximum number of incoming
outstanding RDMA Read Requests that the iSER Layer at the
initiator declares on a particular RCaP Stream.
It might be better to say "specifies for" rather than "declares on" here. I
found the way iSER-ORD was defined to be clearer, also—this definition doesn't
say what effect the iSER-IRD has.
Phase Collapse is a really confusing term—it sounds like something that happens
in an inductor in an AC circuit. Can't you say something like "Phase
aggregation" instead?
1.2 does not define the acronym "RCaP". Personally I'd prefer to see fewer
acronyms anyway, but it seems inconsistent to define so many acronyms in 1.2
and not define this one.
In 3.3:
4. The iSCSI Layer at the initiator MUST NOT issue SNACKs for PDUs.
Which type of SNACK do you mean here? Given that the acronym is defined as
having two meanings, I think you need to specify.
I have only reviewed the things in this document that have changed since 5046. Overall comment: The writeup indicates that there is widespread interoperable deployment. The changes to this document from 5046 seem to document what's actually going on in the field, as against introducing new functionality. Is there a reason that you didn't submit this for full Internet Standard instead of recycling at Proposed Standard? Unless you see an update to this coming soon, it seems like a waste not to try to advance it unless there is a good reason not to. Only a couple of specific comments: 2.5.1: The iSER layer at the initiator SHOULD invalidate the Advertised STag upon a normal completion of the associated task. The Send with Invalidate Message, if supported by the RCaP layer (e.g., iWARP), can be used for automatic invalidation when it is used to carry the SCSI Response PDU. There are two exceptions to this automatic invalidation - bidirectional commands, and abnormal completion of a command. The iSER Layer at the initiator SHOULD explicitly invalidate the STag in these two cases. The last paragraph of this section describes the downside of violating the SHOULDs in the above paragraph. Thanks for that; it's exactly what a document ought to provide whenever there is a SHOULD. But you don't explain the sorts of circumstances that would necessitate not following the SHOULDs: Why are these not MUSTs? 5.1.1: If the outcome of the iSCSI negotiation is to enable iSER-assisted mode, then on the initiator side, prior to sending the Login Request with the T (Transit) bit set to 1 and the NSG (Next Stage) field set to FullFeaturePhase, the iSCSI Layer SHOULD request the iSER Layer to allocate the connection resources necessary to support RCaP by invoking the Allocate_Connection_Resources Operational Primitive. I don't understand why the MUST was changed to a SHOULD, but then again I don't understand why either one is used in the first place: Don't you just mean "the iSCSI Layer will request the iSER Layer to allocate" or "the iSCSI Layer can request the iSER Layer to allocate"? Maybe I'm not understanding the meaning of the requirement here. Is this part of what's being discussed in the new text in 5.1.3? If this is just about the timing, switching the MUST to a SHOULD in this paragraph doesn't make that clear. These may include, but not limited to, MaxOutstandingR2T, ErrorRecoveryLevel, etc. 5046 was correct here: "but *are* not limited to" One more global comment, strictly editorial (and probably pedantic): You've (incorrectly) changed a bunch of "that"s to "which"s. The RFC Editor will probably deal with them, but I don't understand why you did.
Thank you for your help in resolving my DISCUSS.
In 2.1 Motivation
Out-of-order TCP segments in the Traditional iSCSI model have to be
stored and reassembled before the iSCSI protocol layer within an end
node can place the data in the iSCSI buffers. This reassembly is
required because not every TCP segment is likely to contain an iSCSI
header to enable its placement and TCP itself does not have a built-
in mechanism for signaling ULP message boundaries to aid placement
of out-of-order segments.
Isn't the fundamental reason out-of-order TCP segments have to be reassembled,
that TCP offers a connection-oriented service with no alternatives to in-order
delivery to an application? Or are you talking about something else? I note
that pretty much the same text is in RFC 5046, so, I'm probably just not
understanding what's going on.
In 4.1 Interactions with the RCaP Layer
The iSER protocol layer is layered on top of an RCaP layer (see
Error! Reference source not found.)
I think you've already seen comments about problems with cross-references, but
I'm including for completeness.
In 5.1 iSCSI/iSER Connection Setup
iSER-assisted mode MUST be enabled only if it is negotiated on the
leading connection during the LoginOperationalNegotiation Stage of
the iSCSI Login Phase.
I think I understand this, but it might be clearer to say
iSER-assisted mode MUST NOT be enabled unless it is negotiated on the
leading connection during the LoginOperationalNegotiation Stage of
the iSCSI Login Phase.
In 5.2.3.2 Connection Termination Notification to the iSCSI Layer
If the remote iSCSI/iSER node initiated the closing of the
Connection (e.g., by sending a TCP FIN or TCP RST), the iSER Layer
MUST notify the iSCSI Layer after the RCaP layer reports that the
Connection is closed by invoking the Connection_Terminate_Notify
Operational Primitive.
Do the iSER and iSCSI layers treat TCP FIN and TCP RST the same way? is there
any action that's required for one, but not the other? I think (from reading
the sections on recovery) that they're treated the same way, so I'm not asking
for a text change here, just for some clue.
In 7.3.11 SNACK Request
Since HeaderDigest and DataDigest must be negotiated to "None",
there are no digest errors when the connection is in iSER-assisted
mode. Also since RCaP delivers all messages in the order they were
sent, there are no sequence errors when the connection is in iSER-
assisted mode. Therefore the iSCSI Layer MUST NOT send SNACK
Request PDUs. A SNCAK Request PDU, if used, MUST be treated as an
^
Is this a typo?
iSCSI protocol error. The iSER Layer MAY reject such a PDU from the
iSCSI Layer with an appropriate error code. If a SNACK Request PDU
is received by the iSCSI Layer at the target, it MUST respond with a
Reject PDU with a reason code of "protocol error".
draft-ietf-geopriv-relative-location
In 4.5, you don't reference an RFC that describes the encoding, but rather an IEEE document. I do not dispute that this is the right thing to do, because I don't know of an IETF document that specifies this, but one concern I have is that the order of the bits in memory or on the wire is not specified, and the in-memory representation for floating point numbers does vary on CPU architectures of different endianness, including some interesting variations on some ARM processors. I think you ought to specify a wire-format encoding, or find a document you can reference that already specifies it. I find the discussion about covert channels in the fractional bits to be somewhat unhelpful. Under what circumstances would suppressing a covert channel make sense? Is this a privacy concern, or is the concern that someone might use this very narrow channel to attempt to transmit information without being tracked?
While the timestamp shows in the XML, its use and relevance in a relational location system is not discussed. It should be noted that both the located object and the reference point may be in motion. Thus a location may be given at time=t2 with reference to a reference point's location at time=t1 (where t1 is usually <= t2). Obviously, it is also the case that the actual location is timestamped.
An IPR/process-nit DISCUSS-DISCUSS: The IETF last call seems to have gone out saying there are no IPR declarations. The shepherd write-up also says there's no IPR. There is one [1] for draft-thomson-geopriv-relative-location-01 from 2010, and its RAND with possible fee. Is that because the "replaced-by" information wasn't updated (it looks like it was) or perhaps the IPR holder didn't think that the WG draft was really covered or is it some tooling bug? If the IPR declaration does apply then another IETF LC is needed I guess. [1] https://datatracker.ietf.org/ipr/1348/
- 4.2 says this extends PIDF-LO as described in 6848, but this doesn't update any RFCs - should it? (Just asking I don't really care:-) - 4.11: The TLV format appears to only support 255 byte URLs. Is that right? If so, that seems small and worth stating explicitly. - 4.11: The map properties (scale etc) are said to be defined by the MIME type, but then you use an example of image/jpeg - that seems a bit broken. I would have expected some other information than image/jpeg to specify the kind of map and for the MIME type to specify how to render to map. But I guess this can sort of work for now. - 7: If an http URL for a map is used and de-referenced that might expose the location of the target, esp. if the map is for a small area. I think you should note that and, given that (I think) other location URLs are at least encouraged to use TLS, this draft should also encourage use of https and not http URLs. I'd be most happy if you said that https MUST or SHOULD be used:-)
Two points here: 1. As already discussed with Martin, the IANA Considerations section needs to register "geopriv" in the "IETF URN Sub-namespace for Registered Protocol Parameter Identifiers" registry (and we need to make sure that IANA is aware of the additional action). 2. This is a "DISCUSS-DISCUSS" point, with no action needed by the authors: I want to make doubly sure that IANA is OK with tying the allowable codepoints in the new "Relative Location Parameters" registry with the "Civic Address Types" registry. The IANA review does acknowledge this relationship, and the fact that the CAtypes registry is closed to new registrations makes this easier, but I want to talk with Michelle on the telechat and make sure they're able to handle this without any difficulties. I'll also note that because the registration policy for the new registry is "IETF Review", it will be up to the IESG to check new registrations against this linkage, so we need to make sure it's clearly documented in the header of the registry itself.
In 1. Introduction In addition to the relative location, an optional URI can be provided to a document that contains a map, floorplan or illustration. I'm reading this text as saying those are the three choices. Is that what you meant? In 3. Overview This extension allows the creator of a location object to include two location values plus an offset. It would be helpful to this reader if you named the two location values. The following text talks about a "baseline location", but I'm not sure whether that's one of the two location values, and whether it is or not, I'm not sure what the other location value is. Further down in Section 3, The baseline location SHOULD be general enough to describe both the reference location and the relative location (reference plus offset). Location objects SHOULD NOT have all location information in the baseline location. I'm not sure the first SHOULD is a 2119 SHOULD (perhaps something like "needs to be"?), and I'm not sure why the second SHOULD NOT isn't a MUST NOT. In 4.9.4. Polygon or Prism Shape At least 3 points MUST be included in a polygon. In order to interoperate with existing systems, an encoding SHOULD include 15 or fewer points, unless the recipient is known to support larger numbers. Is there any way to signal support for more than 15 points? If not, I'm somewhat uneasy about this being a SHOULD - what you know about other entities in a loosely-coupled distributed system may be true when you discover them, but might change later. Is this saying that a sender might include 18 points, thinking that other peers support 18 points, while being ready to fall back to 15 if 18 is beyond the peer's capability? Does that sound like a good plan for location information being used by a PSAP?
Given that the draft specifies speed and relative direction I am surprised that it does not also specify acceleration.
refered to the adddir review from 4/17 no objection.
draft-ietf-l3vpn-virtual-hub
I really wanted to ballot "Yes" on this document: it is a "Good Thing", and I find no issues of substance. But I am disappointed that the document was presented for IESG evaluation with issues identified by idnits that will require author action to resolve (rather than being purely editorial nits that could be left to the RFC Editor). What reference was intended for [IANA-SAFI]? Only the authors can know what they meant. The IPv4 addresses used in the examples should, as far as possible, be taken from the example ranges specified in RFC 5735. Only the authors can correctly substitute addresses.
Section 14 should be renamed "Informative References"
I'm not convinced that there are no new security considerations here. It may be true that there are no new vulnerabilities, but that's not the same thing. For example, presumably V-hubs are more attractive targets for DoS or to subvert. That is, perhaps the impact of existing vulnerabilites is increased for e.g. hubs which could change the overall risk. And on the positive side, perhaps following this approach might make it easier to start to deploy BGP security mechanisms, e.g. if you start with hubs and then extend out to spokes and vanilla PEs. However, I didn't really understand the thing enough for this to be more than a fairly random passing comment:-)
The shepherd writeup appears to have been written for version -04, and there have been two updates since then. I find it curious, then, that the significant items called out in question 11 weren't fixed. In particular, you need a normative reference to [RFC2119], and a reference is needed to [IANA-SAFI] that also looks like it should be normative (there are citations to both, but the references are missing).
-- Section 2 -- The approach described in this document allows to reduce the number of PEs that have to maintain all these routes by requiring only a subset of such PEs to maintain all these routes. There seems to be a word missing: it allows *who* to reduce the number? Or maybe you just meant to say that it allows the number to the reduced?
In 2. Overview Consider a set of PEs that maintain VRFs of a given VPN. In the context of this VPN we designate a subset of these PEs as "Virtual Spoke" PEs (or just Virtual Spokes), while some other (non- overlapping) subset of these PEs will be "Virtual Hub" PEs (or just Virtual Hubs), with the rest of the PEs in the set will be "vanilla" PEs (PEs that implement the [rfc4364] procedures, but do not implement procedures specified in this document). I'm not parsing the second sentence. Should it be "... *while* the rest of the PEs in the set ..."? But I'm guessing. In 5. Internet Connectivity, in the following two paragraphs: The first alternative is when a PE that maintains Internet routes also maintains a VRF of a given VPN. In this case the Internet connectivity for that VPN MAY be provided by provisioning in the VPN's VRF on that PE a default route pointing to the routing table on that PE that maintains the Internet routes. This PE MUST NOT be provisioned as a V-spoke for that VPN (this PE may be provisioned as either a V-hub, or as a "vanilla" PE). If this PE is provisioned as a V-hub, then this PE MUST originate a VPN-IP default route. The route MUST carry both RT-VPN and RT-VH of the V-hub (see section "Routing Information Exchange" for the definition of "RT-VPN" and "RT-VH"). Thus this route will be imported by all the V-spokes associated with the V-hub, as well as by other V-hubs and "vanilla" PEs. An implementation MUST support the first alternative. Does this MUST apply to all PEs? The second alternative is when a site of a given VPN has connection to the Internet, and a CE of that site advertises an IP default route to the PE connected to that CE. This alternative has two sub-cases: (a) PE is provisioned as a V-hub, and (b) PE is provisioned as a V- spoke. An implementation MUST support the sub-case (a). An implementation MAY support the sub-case (b). Does the sub-case (a) MUST *also* apply to all PEs? So, two MUSTs (and a MAY)? In 7. Multicast Considerations The V-hub/V-spoke architecture, as specified in this document, affects certain multicast scenarios. In particular, it affects multicast scenarios where the source of a multicast flow is at a site attached to a V-hub, and a receiver of that flow is at a site attached to a V-spoke that is not associated with that same V-hub. It also affects multicast scenarios where the source of a multicast flow is at a site attached to a V-spoke, a receiver of that flow is at a site attached to a different V-spoke, and the set intersection between the V-hub(s) associated with the first V-spoke and the V- hub(s) associated with the second V-spoke is empty. It may also affect multicast scenarios where the source of a multicast flow is at a site connected to a V-spoke, a receiver of that flow is at a site attached to a different V-spoke, and the set intersection between the V-hub(s) associated with the first V-spoke and the V-hub(s) associated with the second V-spoke is non-empty (the multicast scenarios are affected if the I-PMSI/S-PMSI A-D routes originated by the first V-spoke are not imported by the second V-spoke). Does everyone (except me) understand what is meant by the several "affects" in this paragraph? Are they all saying that the same thing happens in various situations, or does what happens in each situation differ?
examples should use documentation address ranges if possible. assume IANA-SAFI is http://www.iana.org/assignments/safi-namespace/safi-namespace.xhtml please fix that.
draft-ietf-xrblock-rtcp-xr-discard
Sam Hartman's secdir review [1] of xr-discard-rle-metrics raised a good question that's probably better asked here, or here as well. I'm not asking for any change in this or any specific xrblock document, but I would ask that the WG do consider this. Sam said: "Has the WG analyzed implications of providing feedback to an attacker on what specific SRTP packets are discarded? In the past we've run into trouble with security systems that were too verbose in error reporting. As an example, in certain public-key crypto constructions knowing whether a packet produced a decoding error vs a signature error after decryption can provide an attacker generating forged packets valuable information to attack the system. It's quite possible that SRTP doesn't have problems in this regard. I just want to confirm that the analysis has been done." I think that's a good question because knowing at what stage in a security protocol a message was barfed or getting timing statistics can expose information about how some crypto operation went wrong, and that can be exploited via statistical techniques with a sufficiently large number of messages. See for example the lucky-13 attacks against certain cryptographic modes in TLS [2] or perhaps the "original" of the species, the Bleichenbacher attack. [3] I suspect the best thing to do might be for the wg to try grab a security person and ponder this for a bit, if that's not already been done. I'm happy to try help find a co-ponderer if you want:-) Maybe we can ambush one in a hallway in Berlin. [1] http://www.ietf.org/mail-archive/web/secdir/current/msg04048.html [2] http://www.isg.rhul.ac.uk/tls/Lucky13.html [3] https://en.wikipedia.org/wiki/Adaptive_chosen-ciphertext_attack
-
Block type (BT): 8 bits
A Discard Count Metric Report Block is identified by the constant
PDC.
[Note to RFC Editor: please replace PDC with the IANA provided
RTCP XR block type for this block.]
Figure 1 needs to be changed as well, not only the text.
-
Section 1.4
This metric is believed to be applicable to a large class of RTP
applications which use a jitter buffer.
Isn't a de-jitter buffer? See https://tools.ietf.org/html/rfc5481#section-3.2
My apologies for updating this comment after looking at similar text in the -jt draft. You can ignore my previous comment on -discard. In this text, 4. SDP Signaling [RFC3611] defines the use of SDP (Session Description Protocol) [RFC4566] for signaling the use of XR blocks. However XR blocks MAY be used without prior signaling (see section 5 of RFC3611). This text is saying, to me: - You can signal the use of XR blocks in SDP, - or not - but if you do signal the use of XR blocks in SDP, here's how you would do that for discards Is there any guidance you can give about which choice an implementer should lean toward?
Had the same thought Stephen did.
draft-ietf-avtcore-avp-codecs
Please add the RFC number of the updated RFC to the Abstract such as: This document updates RFC 3551, the RTP/AVP profile (and by extension, the profiles that build upon it), to reflect changes in audio codec usage since the document was originally published.
- s1: "utility is limited" seems wrong, I think you mean that DVI4 is not or no longer attractive given more modern codecs exist. The current text implies that having a more modern codec installed would make DVI4 perform worse or something. - s3, the 2nd para should be indented - I guess this is the one that puzzled Barry and I can see why.
I was initially confused by Section 3, until I read it a few more times, and
realized that the second paragraph is not part of this document, but is quoted
from 3551. Yes, I think I was being dense. Still, I think the quoted
paragraph would get a readability benefit from indentation (as would the
modified version in Section 3.1). If you're using xml2rfc, you can simply wrap
the text with '<list style="empty"><t>' and '</t></list>'.
(Yeh, nothing is so simple that *some* <strike>fool</strike> AD can't
misconstrue it....)
Less trivially:
I think the 2119 usage of "REQUIRE" in the added sentence is not correct. The
protocol is not making this a MUST (for which REQUIRE is a synonym). The fact
that it's required by some environments simply puts a bit of emphasis on the
SHOULD that's already there ("REALLY REALLY SHOULD", in the style of RFC 6919).
I would make the "require" lower case.
(Yeh, nothing is so simple that *some* <strike>nitpicker</strike> AD can't find
something to change....)
draft-ietf-avtcore-6222bis
Using the MAC address of the device for short-term persistent identifiers seems like a privacy problem. 6.2 speaks to this point, but the proposed mitigation assumes that the problem is that an eavesdropper would gain information about the identity of the endpoint using the persistent identifier. In fact, the more likely problem is that the other endpoint would gain that information. I am not the IESG expert on privacy, so I may be making more out of this than is warranted, but I'd really like to see some additional review of the privacy implications of this before it goes out. I assume such review has not occurred because I see no mention of this issue in the security considerations section. Please let me know if I am mistaken. You could clear this DISCUSS either by not using the MAC address, by explaining the working group's rationale for why this isn't a problem in a way that is convincing, or by getting someone with more expertise on the subject than I to review it and explain why it isn't an issue, or by implementing whatever mitigation they suggest. To be honest, given the set of names I see as authors of this document, I assume I am missing something, so please don't hesitate to point out what that is.
The discussion of third-party monitoring in 4.1 is uncomfortable. It seems to be encouraging application developers to add hooks to make third-party monitoring easier, which would be great if we thought that this was only going to be used for performance measurement. But of course it can also be used for tracking endpoints through a firewall, or in the presence of temporary IP addresses. It's hard to see how this text adds value. What was the working group's motivation for including this text? In 4.2, regarding short-term persistent RTCP names, the document says "In either case, the procedure is performed once per initialization of the software," which contradicts the point made in 4.1 about the purpose of these short-term persistent identifiers and the advice that they are not needed for unrelated streams. It seems to me that you could make this better by saying "at least once" to allow for the possibility that they would cycle more frequently.
Like Stewart, I am a little surprised that the algorithm described here is probablistic given that the failure of a previous solution to guarantee uniqueness is cited as a major motivation for this work. Given the contradiction implicit in "probably unique", I think that this document should refresh the readers' minds (even if only by reference) about the consequences of non-unique choice and how such situations are resolved. For example, if the consequence is that there is an extra protocol exchange to force resolution, then that is one thing. But if the protocol will completely fail to work, that is something quite different. But I have no objection to the publication of this document.
- 6552 updates 3550, does this also? I'm just wondering if the "updated by" metadata for 3550 will be preserved or mucked up or what. (Others may know all this, but I don't:-) - 4.2, 2nd bullet: just a query - is there any need to consider base64url encoding here? If so it'd be good to mention since its often a bit of a mess if discovered later. (I've no idea if these names might be sent in URLs or web forms.) - CNAME is a DNS term of art, and the DNS term is perhaps the more widely known. I think it'd be good to distinguish those if that's not already done elsewhere. - For privacy reasons, changing CNAMEs is a fine plan. However, an equally fine plan might be to chose a CNAME from a small set so that transport problems are unlikely but the identifying precision of the value is minimial. Was this option considered? (To make it concerete just to help answer the question, say if N unique values were enough to ensure the probability of a transport problem could be ignored then why not just pick a random number between 1 and N, for the smallest acceptable N?)
Let me double-check something regarding the CNAME length "To locally produce a unique identifier, we simply generate a cryptographically pseudorandom value as described in [RFC4086]. This value MUST be at least 96 bits but MAY be longer." What is the max length? While quickly browsing through RFC 3550, I could not find it. Why is this important? For management: if we need to access the information via a MIB, NETCONF, IPFIX, ... we need the max length. I was unable to tell 1. what is the max CNAME length? 2. if the CNAME max length changed compared to RFC 3550 btw, "we" in IETF specifications is not ideal. Editorial: In Section 6.5.1 of the RTP specification, [RFC3550], there are a number of recommendations for choosing a unique RTCP CNAME for an RTP endpoint. The first link "Section 6.5.1" is wrong. It goes to RFC 6222
I'm a Yes, but did have a couple of comments for the authors. Please consider them, along with other comments you may receive. For those oi us who aren't wizards at security but might still end up implementing this revised algorithm ... in 1. Introduction For a discussion on the linkability of RTCP CNAMES produced by [RFC6222], refer to [I-D.rescorla-avtcore-random-cname]. I thought that reference to the draft was pretty important, but https://datatracker.ietf.org/doc/draft-rescorla-avtcore-random-cname/ is currently expired. I know the reference is listed as Informational, so you won't be stuck in REF-HOLD, but I found the discussion of the linking problem to be short, clear and compelling (where "compelling" means you can tell your boss "If we don't update our implementation, people may die"). If the referenced draft really is stalled, perhaps you could include something like the referenced draft's section 2.1 text (with attribution)? In 3. Deficiencies with Earlier Guidelines for Choosing an RTCP CNAME This document replaces the use of FQDN as an RTCP CNAME by alternative mechanisms. Not to be pedantic, but the same text is in RFC 6222 :-) Perhaps it needs to be updated for the current draft, to point to RFC 6222?
I have no objection to this being published, but I am slightly disappointed that the proposal is for a probabilistic scheme rather than a deterministic scheme, which surely must be feasible.
draft-ietf-xrblock-rtcp-xr-jb
Same remark as for draft-ietf-xrblock-rtcp-xr-discard. jitter buffer versus de-jitter buffer. I know it's mentioned in section 1.4, but some changes would ideal. The draft is not consistent.
In 3. Jitter Buffer Operation Overall user perceived delay = network round trip delay + local (jitter buffer (nominal) delay + encoder serialization delay) + remote (jitter buffer (nominal) delay + encoder serialization delay) This is likely a stupid question, but are both local and remote serialization delays "encoder" delays? Or are "decoder" delays negligible? Or am I missing a term of RTCP art? In 5. SDP Signaling [RFC3611] defines the use of SDP (Session Description Protocol) [RFC4566] for signaling the use of XR blocks. However XR blocks MAY be used without prior signaling (see section 5 of RFC3611). This text is saying, to me: - You can signal the use of XR blocks in SDP, - or not - but if you do signal the use of XR blocks in SDP, here's how you would do that for JB Is there any guidance you can give about which choice an implementer should lean toward?
draft-ietf-mmusic-sdp-miscellaneous-caps
I think it would be helpful to add a reminder of how legacy implementations and those that do not support the new capability negotiations will react when they are attempted. This is probably just a simple one line statement and a reference.
Are these possibly missing security considerations? - The bandwidth capability could be used as part of a DoS if reservations are made based on bad values. For example, if Alice gets lots of bandwidth reserved then Bob might not be able to do stuff. - A premium-rate number could be included in the PSTN thingy.
As I read the internationalization paragraph in Section 3.1.3, I find that I would appreciate an example that shows two titles for the same content, in different character sets. Can you add such an example?
I was able to guess at bcap and ccap, but not at icap (title), and I had to scan for a while to decode that. The 4th occurrence of "title" finally said "*media* title" capability - that helped. Could you consider moving "media title" to the first occurrence of "title" in the doc?
draft-ietf-pkix-est
Balloting No Objection after a light skim and trusting the Security ADs to get this right
D1. The document requires the use of HTTP >=1.1. Why is that the case? It seems like HTTP/1.0 over TLS would be sufficient for what this document is trying to do. Also, the queries in Section 3.2.2 would be valid HTTP/1.0, but are not with HTTP/1.1 (because they lack a Host field) D2. The way Section 3.2. is structured has ambiguities that seem likely to lead to interoperability problems. It took me a couple of passes through Section 3.2 to realize that there are actually 5 different protocols here that have been glued together because they some superficial similarity. It seems like it would be much clearer to organize this section in terms of the EST operations in Figure 5; for each operation, define the URI path it uses and the content types. As it is, it's not immediately clear that you couldn't send a Full CMC message to an "enrollment of new clients" URI.
C1. The comment in Section 1 that EST doesn't define EST over UDP/DTLS seems a little non-sensical. C2. In Section 3.2.1: This document doesn't "profile" the Content-Type header, it requires that specific values be used in it. It seems like this section could be deleted in favor of Section 3.2.4. C3. This may be obvious, but I don't see anywhere in the document that says that the EST application layer MUST NOT be used over bare HTTP, without TLS. This might be good to note explicitly.
I'll end up as a yes for this but I have a few things I'd like to DISCUSS first: (1) I don't get how the client discovers the "arbitraryLabel1" etc in 3.2.1? Don't you need to say that they're assumed to be known to the client? (Or provide a discovery mechanism, which sounds like too much work.) I'm also unsure of the point of using .well-known with those labels, but can live with it. (2) 3.2.1, .well-known URLs will often result in HTTP re-direction. Don't you need to say more for HTTP re-directions, e.g. that whatever is required for the original server cert is also required to be true of the location to which the HTTP client is re-directed? How does the MUST for tls-unique values from the 1st TLS session in 3.5 work with re-direction? I suspect that you need to either work out how 3xx responses are done or else explain it a bit more to me, because I didn't get that it works now. (3) 3.6.1: what does check "against" mean? Don't you need to say more, e.g. URI has to be in a SAN of a TA or something? (Similar question for 3.6.2.) (4) 4.4.2 - is this the 1st mention of SMIME Capabilities? Don't you need it earlier if you use it here? Maybe that's a cut'n'paste error?
- intro, why call out TLS1.1 and have no reference to 5246? I think at least adding 5246 would be good since we would like folks to use TLS1.2 for this (and for everything). I'm fine if this says that it doesn't really matter (in functional terms) what version of TLS you use which is what I think you're trying to say. - intro, would it be worthwhile also saying that this doesn't have any relationship with 6712 (which updates 4210) and sort-of attempts to do the CMP-like equivalent of this? The only reason to add soemthing like that would be to offset reader confusion if they go look at 4210, see its updated by 6712 and then are puzzled that this is very different from 6712. (And yes, all involved, incl. me, are sorry about the 20-th century screw up that lead to us having both CMP and CMC;-) - 1.1: TA as the abbreviation for "Third Party Trust Anchor" seems liable to confuse folks easily. Why not TPTA to be clear? The two TA definitions following seem to already allow for such confusion. - 1.1: certificate-less TLS: what about DH-ANON? There's no uniquely shared credential there. I thought you meant TLS-PSK btw, but its turns out (in 3.3.3) that you really mean TLS-SRP. Better to be clear about that up front. (I'm not sure if TLS-SRP is really wise, but I guess this is a corner case, right?) - section 2, 2nd last para: this isn't really a "profile" suggest s/profile/specification/ - 2.2.3: I think you could re-iterate that that better take place via TLS here, or very bad things can happen:-) (I know you say that in 3.2.3 but still...) - 2.6: MAC addresses in CSR's seems a bit odd, maybe add to the end of that sentence "...of an interface that the EST CA is being asked to include in a public key certificate" (but when does a cert include a MAC address?) Seems like an odd example. - 3.1, 2nd last para, last sentence: saying you MUST be able to disable implicit TA databases seems likely to mean that e.g. you couldn't do a client as a JS application running in a browser or a browser plug-in. Is that right and is that considered ok? Perhaps SHOULD would be better there in terms of getting more/quicker deployment? (3.2.3 also expresses this requirement.) - 3.5 1st sentence: I think s/support/use/ here is right. This is OPTIONAL to support but some servers might REQUIRE it, which is bad for interop, but understandable I guess. (Some server/CA policies will be such that not all clients can work with 'em.) - 3.5: Saying clients are RECOMMENDED to do this but that PoP is OPTIONAL is confusing. - 3.5: If tls-unique is MTI then you should say that in section 3.3 somewhere. (The MUST verify for that in 3.5 makes it MTI for servers at least I think.) - 3.5: Saying that you might need to hash the challenge-password but not saying how seems wrong. I'd say just re-word to say that only <255 byte challenge-passwords are supported here. - 3.6.1: it seems odd to say that id-kp-cmcRA is used to "authorize" an EST server. - 4.1.1: (shameless self-promtion:-) If its useful you could maybe make use of RFC 6920 for that out of band confirmation. No problems if you'd rather not but the nih format might be usable for that and might even help. I expect you'll say that you've already implemented something and its different, and that's fine. - 4.1.1: what is a Publish Trust Anchor "control"? I don't recall the term control before. - 4.2.1: I'm not clear from this what forms of PoP MUST be implemented. Maybe 4.3 will make it clear. (It didn't.) I'd say maybe get rid of discussion of the more complex forms of PoP from here. - 4.2.2: is "rekeys the client certificate" sufficiently clear? - 4.2.2 and elsewhere: If human-readable content is included, how do you know what language to use? Maybe just say the EST server has to know somehow. - 7, 2nd last para: typo: s/it is RECOMMEND/it is RECOMMENDED/ - The secdir review [1] had a few comments that would be good to address, (and I've not seen a response), in particular, a generalisation of this seems worth a mention in section 7: "In 2.6, the additional CSR attributes are non-verifiable data. E.g., if a client puts a MAC address into its CSR, there is no way for the EST server or CA to validate that input. The client can easily insert any data it wants into that request, which can lead to MAC stealing or other impersonation attacks. The CA should never put any normative information into the certificate that it cannot validate from a trusted source." [1] http://www.ietf.org/mail-archive/web/secdir/current/msg04029.html
This document is just mad for 2119 language. There are some places where I think they are used excessively, but I am trying to be on board with Stephen's philosophy of "if it's not going to mess up an implementation, ignore incorrect uses". There are no technical worries that I see. So, I will only mention two silly, more editorial points: Section 2: This section does not include RFC 2119 key words. Really? :-) I suggest deleting the sentence. Section 3.1: The EST client is RECOMMENDED to be configured with... I'm worried what the answer might be, but why didn't you say "The EST client SHOULD be configured with..." instead of contorting the adjective into a place perfectly suited for an auxiliary verb? (You've got similar things throughout the document: "It is RECOMMENDED that clients..." instead of "Clients SHOULD...".) Is there anything other than just a weird writing style that is making you use these strange passive sentences? It's not that you think SHOULD and RECOMMENDED mean two different things, right?
Not sure I've seen any answer to Nevil's OPS DIR review:
I have reviewed this draft. It "describes a simple yet functional
certificate management protocol targeting Public Key Infrastructure
(PKI) clients that need to acquire client certificates and associated
Certification Authority (CA) certificate(s)."
I'm certainly not a security expert, and this is a fine-detailed
document that's clearly intended for people who have a good understanding of
public key infrastructure, in particular RFC 5274 (Certificate Management
Messages over CMS). Nonetheless, it's well-written, and I had no difficulty
understanding how an EST server is intended to work.
When it comes to deploying an EST server, an organisation will obviously
need to understand how pkix works in considerable detail, and to make
sure that its various components will have to interwork properly with
each other. That said, this draft document documents a new service -
as far as I can see - so anyone deploying it will need to be sure that
their existing pki infrastructure will support it properly.
I note that in several places (e.g. section 3.32.3) there's a reference
to "TLS 1.1 [RFC4346] or later versions." That seems like a good idea,
allowing for newer versions of TLS to work with an EST server, however
it does mean that EST implementors will need to check that their servers
continue to work properly with such newer versions.
Question: in section 1.1, Terminology, 'Implicit Trust Anchor:' gives
an example that includes "used by server's to authenticate
manufacturing installed client credentials." Can you make it a bit
clearer just what that really means?
A few small typos:
section 3.4: s/the possesion and/the possesion of and/ ?
section 3.4 s/cipher suite pose such/cipher suite poses such/
section 3.7 /simpleenroll is split over a line break, leaving
a lone / at the end of a line
section 4.2 s/verify the authorization the/
verify the authorization of the/
section 4.2.1 s/used to for/used for/
sections 4.2.3 and 4.3.2 s/informative information/information/ ?
section 4.5.2 s/Csrattrs/csrattrs/ (why the uc C here?)
Cheers, Nevil
These comments are for the editors. Please consider them as your document moves through the process. In 3.2. HTTP Layer HTTP 1.1 [RFC2616] and above support persistent connections. As described in Section 8.1 of that RFC, persistent connections may be used to reduce network and processing load associated with multiple HTTP requests. EST does not require or preclude persistent HTTP connections and their use is out of scope of this specification. If I understand the final sentence correctly, EST works fine whether you use persistent HTTP connections or not. If that's so, and I suspect it is, that's not "out of scope", that's "good news! we've looked at it, and there's no problem". Please consider removing "and their use is out of scope of this specification". In 4.4.1. Server-side Key Generation Request The server needs to know a priori about the algorithms supported by the client. I don't know whether this requirement is typical or not, but I wonder - is there some way this might be signaled?
This seems both explicit and wierdly non-specific. TLS cipher suites that include "_EXPORT_" and "_DES_" in their names MUST NOT be used. These ciphers do not offer a sufficient level of protection; 40-bit crypto in 2013 doesn't offer acceptable protection and the use of DES is deprecated.
draft-ietf-ipsecme-ad-vpn-problem
I have no objection to the publication of this document. Martin Vigoureux posted his Routing Directorate review to the authors and to the ipsec mailing list on the last day of IETF last call. I didn't see a response. The review raises the following non-blocking comments for consideration by the authors before publication as an RFC. > Minor Issues: > > The draft defines and uses the term "endpoint" and "gateway" while > RFC 4301 apparently employs the terms "host" and "gateway" (although > there are few occurrences of "endpoint"). While I doubt that this > difference will be misleading, it might be wise to seek for > consistency in terminology between the documents, or alternatively > state the differences and similarities between the functions these > terms refer to. > > Nowhere is there a requirement for (backward) compatibility with > regards to existing specifications. Is this intentional? > > Requirement 1 is unclear with regards to the type of configuration > changes that must be minimized. It should be clarified if these > changes are manual configuration changes or simply configuration > changes. If not, out of this requirement both the solutions of having > no/few change or having as many changes as today but all/most of them > done without human intervention, are possible. > I can not state if any of these makes sense or is feasible but they > are surely substantially different from a design and engineering > perspective. > As an illustration, Requirement 2 has the same ambiguity but resolves > it by means of the second sentence where the configurations are > explicitly qualified as "manual". > > Isn't requirement 8 too strong? The keyword "MUST" is used, while > "SHOULD" would seem more appropriate. Indeed, follows the requirement > a description of situations in which it might not be possible to meet > the requirement, or where it might be but by means of external > factors. > > While requirement 12 is not an unusual one, its presence in a document > that focuses on point-to-point can be discussed. > > As a general comment it is difficult to estimate how much some of > these requirements scope/guide the design of a solution. > > > Nits: > >Section 2.2: > "It is for this purpose spoke-to-spoke tunnels are dynamically created > and torn-down." This sentence seems difficult to read. --- Please consider consistency of hyphenation. For example: "site-to-site" and "host to host". --- Section 1 I stumbled over The difficulty is that all the configuration mentioned in RFC 4301 is not superfluous. Is this equivalent to The difficulty is that none of the configuration mentioned in RFC 4301 is superfluous. --- Section 1.1 (Hub) The hubs usually forward traffic coming from encrypted links to other encrypted links, i.e. there are no devices connected to it in clear. Seems to be a contradiction between "usually" and "no devices". Should it read: The hubs usually forward traffic coming from encrypted links to other encrypted links, i.e. there are usually no devices connected to it in clear. --- I found requirement 4 to be self-defining (or possibly not saying anything). 4. In the full mesh and dynamic full mesh topology, Spokes MUST allow for direct communication with other spoke gateways and endpoints. In the star topology mode, direct communication between spokes MUST be disallowed. The definiton of mesh topologies and star topology *are* these abilities. But I would also say that it is not the business of the mechanism that is invented to specifically allow or disallow the communications. That is a deployment model. Maybe you are looking for... 4. It must be possible to make a system-wide configuration of whether a mesh topology or star topology is being used, and to enable/limit the provision of keys so as to support or disallow the specific topology. More generally, it must be possible to configure which spokes are allowed to communicate directly. Similarly 11. The administrator of the ADVPN SHOULD allow for the configuration of a Star, Full mesh or a partial full mesh topology, based on which tunnels are allowed to be setup. This seems to be self-defining. --- Should you add a reference for "L3VPN"?
Good to see this being done. I've mostly nitty comments, I'm entirely ok if you take 'em or leave 'em. - 1: "is not superflous" is an odd phrase, better to have a positive statement e.g. "is important but also complex" or something. - 1.1: the definition of spoke is unclear to me, esp. the mention of cleartext. I think you just mean spoke :== endpoint or gateway but only if gateway != hub, but I'm not sure that quite works in a full mesh really since every gateway is then a hub and a spoke. Its probably ok though, but could be a source of confusion later I guess. - 2.1: does endpoint-endpoint direct imply transport mode? its not clear to me - 4.1, req#4: "MUST be disallowed" seems wrong, I think you mean there's no requirement to enable that via the ADVPN, but since they're two hosts on the Internet you can't in general prevent them communicating directly. - 4.1, re1#5: 1st sentence is odd, maybe its not needed as the 2nd & 3rd sentences capture the requirement better. (A public key could be interpreted as a long term credential unless there's a definition of credential that only means things with a private/secret component.) - 4.1, req#6: saying f/ws and NAT "will not be considered" seems wrong - I think you mean that handoff solutions are not required to cater for f/w & NAT oddities but if so, better to say it that way perhaps. - 4.1, req#11: Is "The" administrator correct? Maybe administrator*s* would be better. - 5: SPD should probably have been expanded on 1st use
Thank you for writing a document on this important problem. I'm planning to ballot a Yes vote on the document. But before that I would like to discuss two items. First, it would be good to ensure that the authors have seen Suresh Krishnan's Gen-ART review. Secondly, Suresh raised a question on Section 2.3: > The following sentence is a bit confusing. How does a mobile user > connect to a new gateway without reinitiating a connection? Can you > please clarify or reword. > "The mobile user ought to be able to discover and then connect to the > current most efficient gateway without having to reinitiate the connection." I would also like to see a clarification or rewording, as the way that the current text is written, this seems like an almost impossible requirement.
Here are a number of non-blocking, editorial comments. There are lots more, which I'll leave to the RFC Editor; I've only included some that I think most affect the ability to understand the document. -- Section 1 -- The difficulty is that all the configuration mentioned in RFC 4301 is not superfluous. IKE implementations need to know the identity and The "all X is not Y" construction is pretty much always bad. It usually means "not all X is Y", and should be said that way, but in this case I think "some X is Z" would be a much better way. "...that some of the configuration mentioned in RFC 4301 is important to get right," or some such. -- Section 2.1 -- The need for secure endpoint to endpoint communications is often driven by a need to employ high-bandwidth, low latency local connectivity At first I thought "secure" modified the first instance of "endpoint". You want "endpoint-to-endpoint", with hyphens, yes? (Also, as "high-bandwidth" is hyphenated, so should "low-latency" be.) Such a use case also enables connectivity when both behind NAT gateways. Is "users are" missing after "both"? Also, having two sentences in a row that begin with "Such a use case" is a bit awkward. Misplaced comma and wrong word: OLD In a star topology when two endpoints communicate, they need a mechanism for authentication, such that they do not expose themselves to impersonation by the other spoke endpoint. NEW In a star topology, when two endpoints communicate they need a mechanism for authentication, so that they do not expose themselves to impersonation by the other spoke endpoint. END -- Section 2.2 -- However for voice and other rich media traffic that requires a lot of bandwidth or is performance sensitive, the traffic tromboning to the hub can create traffic bottlenecks on the hub "tromboning"? Is everyone going to understand that term? (I didn't, and I won't tell you what I found when I googled it.) -- Section 2.3 -- Maybe making the first sentence, "A mobile endpoint [...]" would help? I wouldn't mind if the first sentence of the second paragraph read more like actual prose, and less like someone took notes. -- Section 3.2 -- The challenge is to build a large scale, IPsec protected networks that can dynamically change with minimum administrative overhead. I think you need to remove "a", hyphenate "IPsec-protected", and make it "minimal". -- Section 4.1 -- In item (1), the first SHOULD actually makes things muddier, and I suggest removing it. As it is, I read it this way: "you SHOULD do the following set of things: (MUST NOT x, SHOULD NOT y, MUST NOT z)." Do you see how that SHOULD weakens the MUST NOTs if you read it that way? I suggest replacing the first sentence like this: "For any network topology (...), when a new gateway or endpoint is added, removed, or changed, configuration changes are minimized as follows:" In item (6): External factors like firewall, NAT boxes will not be considered part of this solution. I don't understand that sentence in the context it's in. Please say it another way, so it fits better into the requirement.
Not my area of clue, but very clear. I did have one comment for your consideration - the reference to host-to-host transport mode being deployed less often read oddly. I was waiting for the document to say "so transport mode is out of scope, but it included transport mode use cases. Could you think about what that sentence was supposed to imply? One possibility is that you were headed towards "transport mode hasn't been deployed nearly as often, but we're including transport mode because we expect that to change with WebRTC", but you might have been thinking of something else entirely.
draft-ietf-pce-gmpls-aps-req
The secdir review [1] ended up with the authors and AD suggesting this addition to the security considerations, which I think would be good: PCEP extensions to support GMPLS should be considered under the same security as current PCE work and this extension will not change the underlying security issues. Sec. 10 of [RFC5440] describes the list of security considerations in PCEP. At the time [RFC5440] was published, TCP Authentication Option (TCP-AO) had not been fully specified for securing the TCP connections that underlie PCEP sessions. TCP-AO [RFC5925] has now been published and PCEP implementations should fully support TCP-AO according to [RFC6952]. [1] http://www.ietf.org/mail-archive/web/secdir/current/msg04026.html
I agree with Joel. Section 3.3 GMPLS PCE Management is really too weak for a requirement document. It sounds like: "hey, let's put a MIB to satisfy the OPS ADs." Are you really going to manage GMPLS PCE deployment with a read-only MIB module. https://tools.ietf.org/html/draft-ietf-pce-pcep-mib-04 and RFC 4802 are both read-only. This section is not about management, it's just monitoring. The WG should review https://tools.ietf.org/html/rfc5706, and tell us how they plan on "managing" GMPLS PCE? Please review https://tools.ietf.org/html/rfc5706#appendix-A, and answer the different questions.
Abstract
The initial effort of the PCE (Path computation element) WG is
specifically focused on MPLS. As a next step, this draft describes
functional requirements for GMPLS application of PCE.
Was specifically focused on mpls
Is replicated in section 1
also I'm not sure it was
https://datatracker.ietf.org/doc/rfc4655/
is the very first document out the door for pce and it already states it's
applicability to GMPLS. likewise GMPLS is included in the the charter.
3.3
Mibs are not the sole manageability consideration associated with the
application of PCE to GMPLS networks
reliance on other protocols and functions are considerations (e.g. in or
out of band signaling) are a considers
impact on network operations are a consideration.
4.
imho the security considerations section is inadequate. at a minimum it should
cite supporting PCE security considerations secretion of RFC 4655
Some of the items here are nits I don't feel strongly about those but they are inline and I can shift them to a comment. also in section 1 This document provides the investigated results of GMPLS applications of PCE for the support of GMPLS path computation. This document also provides requirements for GMPLS applications of PCE in GMPLS intra- domain and inter-domain environments. awkward This document provides requirements for GMPLS application of PCE in support of GMPLS path computation, included are requirements for both intra-domain and inter-domain environments. 2.1. Path computation in GMPLS network Figure 1 depicts a typical GMPLS network, consisting of an ingress link, a transit link as well as an egress link, to investigate a consistent guideline for GMPLS path computation. awkward Figure 1 depicts a model GMPLS network, consisting of an ingress link, a transit link as well as an egress link. We will use this model to investigate consistent guidelines for GMPLS path computation. fig 2. The client Ethernet service could be provided by a VC4 connection Virtual Concatenation is not a connection it's a mapping. 3.1. Requirements on Path Computation Request As for path computation in GMPLS-controlled networks as discussed in section 2, the PCE should consider the GMPLS TE attributes appropriately once a PCC or another PCE requests a path computation. Indeed, the path calculation request message from the PCC or the PCE must contain the information specifying appropriate attributes. According to [RFC5440], [PCE-WSON-REQ] and to RSVP procedures like explicit label control(ELC),the additional attributes introduced are as follows: Starting an entirely new section with a subordinating conjunction is super painful it implies this is part of section 2 If this is just a subsection of section 2 then great it should be reorganized. Otherwise, consider: The PCE should consider the GMPLS TE attributes appropriately once a PCC or another PCE requests a Path computation in GMPLS-controlled networks as discussed in section 2. Appropriately really needs to be qualified as the the numbered elements below. remove Indeed 3.1 (4) if we are referring to the network technology in it's entirety is not G.709 OTUk not G.709 ODUk since the later is the wrapper for other client signals?
draft-ietf-nvo3-overlay-problem-statement
Minor nit: While an overlay-based approach may address some of the "pain points" that were raised in ARMD (e.g., better support for multi-tenancy). Analysis will be needed to understand the scaling tradeoffs of an overlay based approach compared with existing approaches. I think you want a comma between these two chunks; otherwise it doesn't really parse. In 5.7, trill-fine-labeling is in the RFC editor queue, so I think that should be described as completed work, rather than something TRILL is investigating. In general this draft is very clearly written, and does a good job of analyzing the problem space. Thanks for doing such a good job on it!
Thanks for this document which I believe is a major step towards scoping and documenting the real problems in this space. I have a number of fairly editorial concerns that I hope you can work through with your AD and document shepherd. --- In reading this document, I found it difficult to distinguish the requirements that arrise from the provision of multiple virtual networks on a common infrastrucutre (traffic isolation, address space isolation, virtual network creation and configuration) from those that are specific to the NVO3 scope (massive scaling, multi-tenancy on individual physical servers, no constraints on physical location of hosted services). --- [I-D.ietf-nvo3-framework] is used as a normative reference because it defines terminology used in this document. --- I would move the definiton of "in-band virtual network" from section 2 to section 5.3 (the only place the term is used) to avoid complicating the definitions with concepts that appear to only be applied to L2 networks. --- Why is the example of an Overlay Virtual Network in section picked from the layer 2 space when this work is supposed to consider only layer 3 overlays? OTOH, since this term is not used anywhere in the document, I suggest deleting it. --- I believe section 3.1 could be rewritten without the need to say "cloud" or "elastic services". This would be helpful because those marketting phrases do not add to the meaning. I think the final sentence of the paragraph captures the issues, but could be pulled out into a little more explanation of what happens and what problems it causes. --- Section 5.3 uses the terms C-VLAN, S-VLAN, and B-VLAN, but only C-VLAN has been defined. -- Section 10 seems to me to be missing the impact that one virtual network might be able to have on another (for example by stressing network resources to cause undesirable VM mobility, or by consuming shared resources to make b/w or CPU unavailable). This is a type of self-consuming DoS.
The nodes of a virtual network, once running, can look after securing their own traffic. That might lead one to say that nvo3 traffic isolation doesn't need to consider confidentiality. However, if the nodes in a virtual network are VMs and if VMs can be moved, then any secrets required for the virtual network to secure its traffic will be exposed to the underlay during the move. I'm not clear if this wg will try address that issue or not. Section 10 does say that some environments might be concerned about confidentiality but is vague about whether or not the wg will work on the topic. Such a confidentiality service isn't a panacea of course, the underlay components providing the confidentiality service could leak the relevant keys, but it could still be useful nonetheless. (BTW, I've no idea if it'd make sense to have such a service that's separated from whatever technology is used to move the VM or not.) So I was wondering: will the wg actually define such a confidentiality service or not? The response is that yes, this'll be considered for the requirements documents which is fine. Note that I'm not trying to insist on a "yes" answer, even though I think that'd be good. Even a "maybe, and that'll be answered in the requirements specs before we re-charter" would be ok. But regardless of the answer, I think it'd be good to at least note this issue in the security considerations section. - 4.1, bullets: I found the use of ingress/egress non-intuitive here. You mean ingress to the underlay and egress from the underlay, right? It'd be good to explicitly say that, though I figured it out eventually (or not, if I'm wrong above:-)
Thank you for writing this document. It is well written and easy to read, and documents the space well. I had one question when reading Section 4. I was wondering why MTU was not mentioned, MTU issues being one of the impacts of overlay designs.
Editorial: In Section 5.6, I think the second and third sentences need to be merged with a comma.
I did have one comment. Please consider it along with any other comments you receive. This draft uses the word "cloud", which has been an extremely imprecise term in the IETF. The second occurrence in Section 3.1 provides some guidance on which of the (many) aspects of clouds you're talking about: Cloud computing involves on-demand provisioning of resources for multi-tenant environments. Could this explanation be moved to Section 1, with the first occurrence of "cloud"?
I support Stephen's discussion position.
draft-ietf-6renum-gap-analysis
Former DISCUSS text:
This document seems unclear as to the exact scenario it is addressing. If it
is essentially addressing the scenario described in RFC 4192, the document
needs to be reviewed to make sure that the gaps identified are real gaps that
could actually happen in an RFC 4192 scenario. If that is not the scenario
that this document is intended to address, the document needs to clarify what
scenario it does intend to address.
I've mentioned in the comments a number of cases where the document doesn't
appear to be referring to use cases that could actually happen in an RFC 4192
scenario; I'm concerned that as it is written, it will lead readers to
misunderstand how renumbering ought to work, and will actually lead them to do
things that make their lives worse during a renumbering event. At the very
least, I think the document needs to strongly state that it presumes the reader
already has a clear understanding of RFC 4192, because if they read this
document without reading 4192, I really think they will get the wrong
impression.
I think the document is going in a good direction, and I would support
publication if this problem can be addressed.
Suggestion in section 2:
OLD:
o Hosts that are configured through DHCPv6 [RFC3315] can reconfigure
addresses by starting RENEW actions when the current addresses'
lease time are expired or they receive the reconfiguration
messages initiated by the DHCPv6 servers.
NEW:
o Hosts that are configured through DHCPv6 [RFC3315] obtain new
addresses through the renewal process or when they receive the
reconfiguration messages initiated by the DHCPv6 servers.
The reason for the proposed change is that renewal doesn't happen at expiry
time, and addresses aren't changed through the Renew process. The current
text is less specific, but probably specific enough for the context, and I
suspect more helpful to the reader at this point in the document.
In section 4.1, I'm really skeptical that this paragraph bears any relationship
to reality for any enterprise setting larger than a SOHO configuration:
Usually, the new short prefix(es) comes down from the operator(s) and
is received by DHCPv6 servers or routers inside the enterprise
networks (or through off-line human communication). The short
prefix(es) could be automatically delegated through DHCPv6-PD. Then
the downlink DHCPv6 servers or routers can begin advertising the
longer prefixes to the subnets.
Are you actually seeing this in practice? I would expect an enterprise-level
site to have a negotiated prefix which is statically configured and controlled
via contract, not via protocol. This scenario certainly could happen in a
home environment or a home office environment, but this document doesn't seem
to be addressing that use case. You do mention off-line communication in
parentheses, but I really think that should be what you lead in with—it doesn't
make sense to me otherwise. I am of course willing to be persuaded on this
question—I think it's a bit speculative at the moment since I don't know of a
lot of enterprises that do production IPv6 internally yet. Did you ask the
Google guys what they do?
In 4.2:
When subnet routers receive the longer prefixes, they can directly
assign them to the hosts. Host address configuration, rather than
routers, is the primary concern for prefix assignment which is
described in the following section 5.1.
What does it mean for a router to assign a prefix to a host? Do you mean
"advertise a prefix on a link to which hosts are connected?"
In 5.1:
Another limitation of DHCPv6 reconfiguration is that it only allows
the messages to be delivered to unicast addresses. So if we want to
use it for bulk renumbering, stateless DHCPv6 reconfiguration with
multicast may be needed. However, this may involve protocol
modification.
This is not accurate. The DHCPv6 server has a complete list of all clients on
any given link. It can issue unicast reconfigure messages to each client, if
desired. Multicast DHCPv6 reconfigure is not an option, because it's too easy
to use it for a DoS attack.
I notice also that you don't mention the 'A' bit in router advertisements. I
think this bit also affects the behavior of various stacks; I'm not sure, but I
think it probably should be discussed.
Section 6.1 talks about DDNS as a way to update IP addresses on names during a
renumbering event. I'm not at all clear on what the use model for this would
be. If we're renumbering servers, then certainly you could configure each
server with its own key to use for doing updates, so that it could poke its new
SLAAC- or DHCPv6-derived address into the DNS. I'm not sure this is a good
_idea_, but it's eminently doable.
The document seems to mention RFC 4704 in passing, without citing it.
Possibly the authors aren't actually familiar with RFC 4074, but just thought
that some commercial servers might have custom solutions to this problem? I
think RFC 4074 entirely addresses this problem, at least for hosts that can be
numbered using DHCPv6.
The combination of RFC4074 and server-oriented DDNS could probably address most
of the problems one might care about with respect to the problem 6.1 is trying
to address. Of course, there is still a gap here, since servers have to
somehow notice that their address has changed and trigger the DDNS update.
The document also mentions A6 records here, which are deprecated (RFC 6563),
and therefore ought not to be mentioned.
In 6.2:
(Addresses of DHCPv6 servers do not need to be updated. They are dynamically
discovered using DHCPv6 relevant multicast addresses.)
While this could be true in principle, it isn't true in practice, because most
relay agents have the option of being configured with DHCPv6 server addresses
rather than sending to a multicast address, and I think it's more common to do
unicast than multicast for this step. So the document shouldn't assume that
this is a solved problem. Even in the case of multicast, it's necessary for
multicast routing to be configured and working in order for DHCP messages to
find their way to servers. In theory a renumbering event shouldn't break
multicast routing, but in practice it might.
The DNS server addresses for hosts could be configured by DHCPv6. In
stateless DHCPv6 mode [RFC3736], [RFC4242] allows the server to
specify valid time for the DNS configuration. But in stateful DHCPv6,
current protocols could not indicate hosts the valid time of DNS
configuration. If the DNS server has been renumbered, and the DHCP
lease time has not expired yet, then the hosts would still use the
old DNS server address(es). It might be better that the hosts could
renew the DHCP DNS configuration before the lease time, especially
there might be some extreme situations that the lease time need to be
long. In this case how the DHCP server could learn the proper DNS
configuration valid time is also an issue.
There are a bunch of problems with this. First, the stateful DHCP T1 and T2
times are effectively equivalent to the stateless DHCP Information Refresh
Timer (DHCPv6 doesn't talk about leases or lease times, so this term should not
be used; rather, addresses have lifetimes, and IAs have T1 and T2 timers that
indicate to the client when to renew or rebind, respectively). So there is no
need for an additional timer in stateful DHCPv6; indeed, it doesn't make sense
to add one just for renumbering. How would you know what value to set it to?
Why wouldn't you just set T1 to that value?
Next problem: in a typical renumbering scenario, the old and new prefixes are
both valid. The old prefix is deprecated, but still works. So the DNS server is
still reachable at the old address: there is no interruption of service.
Deprecated addresses and prefixes decay gracefully, so that by the time they
are gone, everybody has renumbered. Hence, the scenario being described here
should never happen unless someone unconfigures the deprecated address on the
DNS server before all the hosts have stopped using it. That would be an
administrative error.
Section 6.3 appears to be a pair of solutions, not a gap. It is described as a
gap, in the sense that the solutions are lacking, but it's not describing the
actual gap. This seems to be putting the cart before the horse. The right thing
to do is to identify the gap that this solution would fill, rather than
describing the absence of these solutions as a gap.
I think the gap you are talking about is that there isn't a way to trigger
configuration updates for all the subsystems on a server, and all the external
databases that refer to that server, on the basis of a change to the server's
IP address. I am not positive that you need to change the way you are
approaching this, because I think the solutions you are talking about are
interesting, but this section really doesn't feel like it's a gap analysis as
written, so starting from what the gap is and talking about how it could be
addressed might help.
More examples in this section might help: I think the tunnel endpoint example
is a really good one to use. There are probably some other examples that would
be good here—e.g., I have static IP addresses configured in my nginx
configuration. This isn't really the gap—I ought to just put domain names in.
But unless the tunnel endpoint or nginx notices that the addresses returned for
that domain name have changed, it will keep blindly using the old address until
something triggers it to do a refresh or a restart. You mention this in 5.2,
but it should be mentioned here as well, since as far as I know most services
do not actually refresh DNS information until they are triggered somehow to do
so.
In section 7.2, what do you mean by "no mechanisms?" RFC 4192 talks about how
to address this issue, if I understand the issue correctly. Or is the gap you
are talking about the lack of a way to set all the TTLs for a zone to no more
than a particular value?
Section 10.2 mentions the A6 record again. I don't think this is helpful,
because it died for a reason. I think you should leave this out. Also, I
think you need to lead in with the authority problem—my first read of this
section really puzzled me, because it seemed to be talking about a problem that
is easy to solve, and it was only when I saw the acknowledgement in section 13
that I went and read the chown draft and then reread section 10.2 and
understood what the gap was that was being documented.
It looks like 10.3, second bullet, is talking about the problem I mentioned in
6.3 with services not refreshing DNS information. I think the techniques you
talk about in 6.3 can address this problem, so I don't think it's an
unaddressable gap. If this isn't the gap you are talking about, a bit more
exposition might be required...
- The write-up notes that this is similar to RFC 6879 which is recent, on the same topic and has overlapping authors. I was surprised the intro didn't say why this is different. Are we sure there is no conflicting advice in the two documents? - Surely there's a gap in re-numbering when both v4 and v6 numbers have to change at once - why isn't that mentioned here? (I assume because of the wg charter or something.) - p5: "performed integrally" isn't very clear but I think I get that you mean as an atomic operation or something - section 2 last para, not clear to me what you're saying about SLAAC - sentence is odd - p6: "like [cfengine]" is not so nice as a way to reference whatever that might be, same for others - p8, what is "M/O"? you should say - p11, what is "a gao"? - p12, presumably automated approaches like LEROY increase the risk since a bad actor with the right permission could cause havoc - is that noted? - p13, presumably changing DNS RRs means signing things if DNSSEC is in use - is that noted? - p14, ingress filtering - if I could tell an ISP to no longer drop packets with sources from prefix X (because I claim to be renumbering) then I would defeat anti-spoofing measures - is that noted? - 7.2 - do DNSSEC RRSIG validity periods play into this too? - general: if addresses for mail servers are exposed via SPF, then presumably those will need renumbering too; renumbering might also trigger false positives or negatives for anti-spam features (not sure what v6 stuff is being done for DNS RBLs) - I think section 11 should note that if you do attempt to fill soem of these gaps, then you may create new threats and those will also need to be addressed; and some of those will be *very* hard problems to solve
Thanks for addressing my DISCUSS
I support the publication of this document and only have a few, non-blocking, comments/questions... 1. This document is clearly focused on the planned renumbering events within a network and does not address the issues surrounding emergency renumbering events. Did the WG consider the two distinct cases? Would it make sense to add some text to the Abstract/Intro highlighting the focus so people don't think this document covers emergency renumbering events? 2. It may be useful to point out in either 3.1 or 3.3 that administrators can leverage the address selection policy distribution mechanism in draft-ietf-6man-addr-select-opt to update the address selection policies on hosts during renumbering. 3. The 2nd paragraph in 5.1 is rather obtuse. It says that combining SLAAC and DHCP-based address configuration "would add more or less additional complexity". I would think that it would add complexity, period. It might be useful to reword this to make the meaning clear. 4. In 7.1, it mentions a possible notification mechanism to signal a change in the DNS system related to a renumbering event. It may be worth mentioning that such a notification mechanism will need a robust security model.
Just checking on whether these are things people think about when renumbering: 0) s11, prefix validation: Is there any reason it's not: "Prefixes from the ISP need authentication to prevent prefix fraud." In other words what's up with the "may"; when wouldn't you need authentication? 1) s11: Do you also need to discuss issues with long-lived sessions and how to keep them alive or not (e.g., ssh connections)? 2) s11, influence on security controls: a) If there's DHCPv6 authentication keys associated with an IP address they'll need to be changed for it to continue working - no? Addresses in SEND certificates are going to need to get updated. Are these further examples of what you were thinking or is this more about keeping the security up and running during the transition? b) More generally, you can include IP addresses in certificates and if you go and renumber those protocols might, well really will, stop working until you reissue a new certificate with a new address. Is this covered someplace else, does everybody know to do this reissue dance, or should there be a new section "Influence on Security Protocols"?
draft-thornburgh-adobe-rtmfp
(This is very similar to Jari's discuss. If it makes sense to just keep one of them open after the call I'm fine with that.) I echo Jari's discuss which was also an issue identified in the secdir review. [1] I do however also appreciate Martin's explanation that the spec as-is has some utility, and I also really welcome the author's willingness to publish this, but I think the situation needs to be clarified in section 1. Since I'm not sure what does or doesn't work without the security bits I can't suggest text unfortunately but I'd say a note along these lines in section 1, and an accompanying bit of text somewhere else with details of how to work without the security bits would do. I think something like that additional section is really needed though since I can't see how you get even insecure interop as-is. If adobe or the authors were also willing to say "and we plan to publish the security bits in a future specification" that'd be even better. (Note: I'm not trying to insist on that, I realise promises like that might be hard to make.) Another alternative might be to hold this draft until the security bits can be filled in. I could understand if the authors would rather not do that, but it might be easier than defining an insecure-but-interoprable version of this protocol. Personally, I'd prefer that if it were possible since putting out an RFC with only a null/null ciphersuite well-defined seems a bit off. [1] http://www.ietf.org/mail-archive/web/secdir/current/msg04045.html
- 1.1: Saying the security is "always on" seems wrong when that's not specified here. The first three security bullets should be rewritten to say that the security bits are currently missing. (Or move those to the putative section I suggested adding.) - 2.1.2: Interesting that your VLU's are the same as DTNRG's SDNVs. [RFC6256] I'm not suggesting a change just interested that they're the same. - 2.2.3: I think you should also re-iterate here that there is no "Cryptography Profile" currently publicly specified. - 2.3.6: I didn't get why or when its ok to replace a cookie that was incorrect? Seems like a bad thing to be doing. (And what hash function do you mean?) - 2.3.7: initiatorCertificate: what certificate format do you mean? RC5280 or something else? And do you mean just one cert or a chain? - 3.5: If you add the security bits, don't you need some more state for certificate status checking, e.g. to do OCSP?
I'd like to understand what the lack of a profile specification means for interoperability and the ability of others to use this spec.
I believe this document obviously belongs with the ISE instead of as an individual submission via AD, but I have no intention to stand in the way of its publication. I trust Martin to get the non-consensus template on the document. I have reviewed this strictly as if I were doing a conflict review, and I find no conflict between this and IETF work. But because I do think it belongs with the ISE, I simply Abstain.
I'm a Yes, because anytime we can document protocols with significant deployment, that's helpful for network operators.
Whilst I agree with Spencer on the utility of the protocol, the Abstract and the introduction needs to make it clear that this is a proprietary protocol, and not a protocol endorsed by the IETF. Whilst in this particular case this may be obvious, we need to hold all vendors to the same standard.
draft-sparks-genarea-imaparch
In section 2:
- The system must not require credentials for accessing lists
with open archives. (However, it is acceptable for a user to
access such archives while providing credentials.)
I think this isn't quite right—it's really _necessary_ for a user to be able to
access the archive either with a registered password or with either an
anonymous login, or anonymous access.
How about this:
- The system must allow access to open archives with or without
providing credentials.
The rest of the text then nicely addresses how to not provide credentials. :)
I agree with Pete's suggestion to use quotas rather than requiring the
administrator to make user-specific decisions.
In general, I strongly support this effort, and intend to use it extensively
once it becomes available. Thank you for working on it.
I will switch this to "Yes" after we DISCUSS. I posted this to the IETF list to
sanity check:
o It must be possible for administrators, on a per-user basis, to
disable setting read/unread marks and other annotations and to
delete any such marks or annotations.
I don't think that's the appropriate requirement. A perfectly reasonable way to
address the issue of annotations taking up too much space is to use per-user
storage quotas. I would prefer not to give administrators the ability or the
need to decide which users get to use annotations and which users' annotations
they get to delete. And I can imagine servers for which implementing this
requirement would be a significant pain. Quotas solve the problem in a much
more general way.
I have one question: Is getting wrong or falsified copies out of this a threat? I.e., if somebody is getting a full copy of a list, modifies the copy and uploads to some other server claiming that this is an authoritative copy? Somebody could insert "not so nice" emails in this copy and start a campaign.
Robert,
- Excuse my ignorance regarding the annotation (not time to research this now)
The interface should allow users that have provided credentials to
each have their own read/unread marks for messages. Allowing
other annotation is desirable. The implementation should consider
taking advantage of the IMAP extensions for ANNOTATE [RFC5257] and
METADATA [RFC5464].
Is this annotation on a per-user basis?
I guess so when I see:
The interface must not allow users to modify the underlying
message or metadata other than the read/unread marks and
annotations described above.
-
Discussion of this memo should take place on the ietf@ietf.org
mailing list.
do you still need this sentence?
Or is this sentence about the solution design, referring to "and it is intended
as input to a later activity for the design and development of such a service."
from the charter?
I remain nervous given the consequences of an error by the server operators, but since the apps folks tell me it's OK I will not block the draft.
I'd love to support certs on this but as Robert points out this draft uses the authentication mechanism supported by the datatracker. When the datatracker supports certs ... then we get certs with this.
draft-housley-rfc2050bis
Just checking something in case it was missed. I hope this doesn't open cans of worms. If it does... apologies in advance;-) (1) RFC 2050 section 6 describes an appeal process. It seems reasonable for 2050bis to not even talk about how appeals work up to the level of appealing to IANA, but you could read 2050 in conjunction with 2860 as meaning that if IANA receive such an appeal, they might then ask the IESG (with a possible appeal later to the IAB). This document might therefore be read as getting rid of that bit of appeal process (if it ever existed) that involved the IESG & IAB. Is that correct? (I'm not sure and happy to be corrected if I'm reading it wrong.) If so, was that discussed during the IETF LC? (I looked and didn't see it.) If the appeal path I postulate here was real, then it would appear that the sentence in the abstract that 2050bis doesn't change anything isn't quite right. Or perhaps that 2050 section 6 appeal process was already changed by 2860 or ICANN by-laws or something else later on?
These may read like I'm more concerned than I am, but they're really just nits, and I'm ok if they're treated as nits. It might however be worthwhile thinking about them if this is considered an important RFC, given that it may be another 17 years before its touched again. So take 'em or leave 'em, and either's ok with me. - section 2, bullet 1: the fixed length of IPv6 addresses doesn't seem to me to imply that allocations "must" be made in any particular way solely because of the size of the number space. The size of the IPv4 space also doesn't matter now that its gone. And with 32 bit AS numbers that should also be ok. - s2, bullet 2, typo: s/aggegated/to be aggregated/ - s2, bullet 2: What is our level of confidence that allocation processes and routing technology will develop in tandem? If we've no a-priori reason to suspect that's likely then is it really wise to bind allocation and routing like that? (Assuming it'll be another 17 years until this gets updated again.) Maybe better to just say that that's how its done today and not try justify that based on routing. That might be sorted with a trivial change e.g. to s/it is a goal/it is currently a goal/ - s2, bullet 3: "uniqueness" of what? - s2, bullet 3: accuracy doesn't seem to me to be a goal of a distribution scheme but rather a bookkeeping requirement for any distribtution scheme that also has an accountability goal. Is the real goal here that those involved in distributing number resources and those using those resources can be accountable? If so, saying so might be better. - s2, generally seems to be justifying the status quo when it might be better to just state that this is the status quo, its working ok and so there's no reason to mess with it. - section 3: defining IANA like this ignores their role in most of the protocol registries they operate. I'd suggest s/allocation hierarchies./allocation hierarchies as well as managing many other protocol registries on behalf of the IETF./ or something like that.
A strictly procedural point, and it does not prevent this document from moving forward at all, but we should figure out what the "right" thing is here. I'm forwarding to the RFC Editor to get their feedback: This is an Informational document that is Obsoleting a BCP. I am convinced that everyone during Last Call understood the implication of that, so I don't think we need to go back and do something special there. But does the IESG need to do some magical incantation to remove BCP 12 from the BCP Index? We could make 2050 HISTORIC, which would make it clear, or simply treat it as bookkeeping on the RFC Editor web site. This is the first time I've ever seen this happen, so it's not surprising we don't have a procedure for this.
This doc seems fine. I do have one question that could very well be unrelated, but I'll ask anyway. This doc uses the word "multi-stakeholder" in Section 5, but doesn't define it. There are a number of fine words in the following paragraph, but I'm not seeing anything that looks like "and by 'multi-stakeholder', we mean ...". My understanding was that we've been running into people who don't have the same understanding of that word that we do (to the point of "of course we're multi-stakeholder! we invite ALL the governments!") Is there anything like an agreed-upon definition this document could reference? If not, is this the wrong place to say something about what we think that word means?
The IANA site points to RFC2050 as technical documentation in at least one place. I am therefore surprised that there is no IANA action to trigger IANA to update their document pointers.
r/RFC 1366/[RFC1366] and add it in the references section.