IESG Narrative Minutes
Narrative Minutes of the IESG Teleconference on 2014-06-26. These are not an official record of the meeting.
Narrative scribe: John Leslie (The scribe was sometimes uncertain who was speaking.)
Corrections from: Benoit
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
1158 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
1225 EDT entered executive session
(at 2014-06-26 07:30:18 PDT)
- I was a bit surprised not to see an OGA value being defined for e.g. sha256. Why is that not here? (Put another way, I didn't get the meaning of the 2nd para of section 6.) - No need to answer this if you don't care, which is probably the case, I'm just curious:-) We added a special reserved value to RFC6920 for ORCHIDs. Should that now be changed or something?
Thanks for doing this document.
Thanks for http://tools.ietf.org/html/draft-ietf-hip-rfc4843-bis-07#appendix-B. Always appreciated. Below is the OPS-DIR review from Sue. Technical/Administrative issue: The IANA text for section 6 clearly identifies the IANA registry. However, I’m not clear about the form IANA wants to review the entry for this table: http://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xhtml The authors should verify with IANA that the form of their IANA consideration sections is as IANA wants to see it. Editorial Nit Comments (should fix, but not required) Section 5 paragraph 2 Old: “Therefore, the present design allows to use different hash functions to be used per given Context ID for constructing ORCHIDs from input bit strings. “ New: “Therefore, the present design allows the use of different hash functions per Given Context ID for constructing ORCHIDS for input bit strings.” Grammatical note for Julien and Francis: Old sentences utilizes the infinitive form (to use/to be used) without having any real verb. Since this is a specification going with the present tense verb provides a precise definition.
I think the draft looks good and would just like to discuss adding additional guidance if needed as I am not clear on how something is handled and would like to see if additional guidance will assist with security and interoperability. The draft includes design choices in section 4, the first being: o As many bits as possible should be preserved for the hash result. There is no minimum requirement for preserving bits or mention of the space left for these bits (that I could find and maybe they are somewhere else?). The current guidance is in RFC2104 and says to is to truncate no less than half of the length of the hash output. Is there space for more than half? If so, this guidance should be included, if not, a warning that it is not possible would be helpful.
Good update, and I'm glad this is going to Standards Track. The IANA considerations has a slight change due, which we discussed.
This review is based on the diff from 5201   https://tools.ietf.org/rfcdiff?url1=rfc5201&url2=draft-ietf-hip-rfc5201-bis-14.txt Work started on this in 2009 it appears and the backwards incompatible changes made to the BEX are roughly what I'd expect to have seen for good work done around that time. However, some things have changed since, that I don't see reflected in the changes made to the BEX, so I'd like to chat about those for a bit, in case they're still malleable. If it is really the case that the boat has sailed for such changes, then that's life, but I wonder has it? (I really don't know for HIP.) I think the features in the changes to the BEX that one would consider noteworthy were that work done today are: (1) Mandating some form of variability of, and confidentiality for, the (non-routable?) HIT to enhance privacy or at least mitigate trival passive tracking of activity across time and different connections. (Or maybe the "anonymous HI" mechanism achieves this, I wasn't sure? If it does, then why have any other?) (2) There is no support for newer elliptic curves or representations like 25519. (3) Continuing to support the 1536 MODP DHE group but not supporting the 2048 equivalent seems a bit odd, as does not having a code point for the 4096 but group. Similarly, making the 1536 bit group the MTI (in 5.2.7) is odd as is the assertion that "web surfing" can use a lower security level. (4) (5.2.8) Did the WG discuss deprecating the NULL encryption option? (Haven't you finished testing yet:-) Also - there are no counter modes, is that wise? Finally, HIPv1's encryption codepoint 1 was for a 3DES option, but here you have 1 == NULL, yet you deprecate codepoint 3, which is confusing. Why is that? (5) Requiring HMAC-SHA-1 in 6.4.1 seems a bit odd. If HMAC-SHA-256 is supported, then why not just use that? Is there are real benefit in the sha1 variant?
- abstract: SIGMA-compliant is a bit of a mouthful for an abstract - how many readers do we really expect to get that? - 1.1: Saying the HI is the identity of the host seems a little overstated to me, but I guess that's accepted as a description for HIP, so not objecting, but it'd seem more natural to me to say that a HI is an identifier that a host can use. (Presumably load-balancing and mobility scenarios could mean that a private key could be on more than one host or one "host" might have >1 private key.) - section 3: 3110 doesn't seem like a great reference for RSA. Isn't there better?
The Gen-ART review from Tom Taylor raised a couple of issues that in my mind require at least clarification. The authors have acknowledged the review, but I think we still need to see you answer if changes are necessary. Otherwise I am very happy with this document, and will be happy to recommend "Yes" for it once the above is clear.
I have no objection to the publication of this document, but I do have two small points to discuss in section 5.2.3. 1. The R1_COUNTER parameter was labeled as optional in RFC 5201, but made mandatory in this revision. However, the text says it SHOULD be included in R1. If it is not included in R1 (violates the SHOULD), where will it be included given it is mandatory? 2. The Type value of R1_COUNTER was 128 in 5201 and is now 129. Is that correct?
This review is based on the diff.   https://tools.ietf.org/rfcdiff?url1=rfc5202&url2=draft-ietf-hip-rfc5202-bis-05.txt - Why is NULL confidentiality MTI here?
I support Stephen's discuss
-- Section 5.1.2 -- The table of suite IDs includes "NULL-ENCRYPT with HMAC-SHA-256", but NULL encryption is referred to as just "NULL" everywhere else in the document, as well as in RFC 2410. Should the table be consistent with the text, or should there be an explanation of why it isn't?
In 6.2: A peer MAY choose to maintain a fixed-size predecessor list with only three entries as specified in RELOAD base. However, it is RECOMMENDED that a peer maintains ceiling(log2(N)) predecessors. I see that this text is the subject of negotiations with Pete, so I don't want to belabor it too much, but it seems to me that the only reason a peer would choose to do this would be that it didn't support self-tuning, since it seems that supporting a short predecessor list would make the node vulnerable to failures that the longer list is intended to prevent. The motivation for allowing this behavior is thus unclear to me. It may be that it's explained adequately and I missed it, but if not it might help to explain it here. This is really cool work, and I greatly enjoyed reading it. Thanks for documenting it!
Thanks for producing this document. The static configuration seemed kind of lame when I was following RELOAD more closely - this seems like a much better idea!
Providing a way to estimate N seems like a fine improvement over 6940. Good stuff. - 5.6: What does a "better predecessor" mean here? Asking because there's stuff you MUST do when you find one. - 5.6: I also wondered if there's any security issue associated with having a MUST there - could a leaving node use that to force its successor to talk to nodes the leaving node has chosen for some nefarious purpose? (Apologies, I forget RELOAD, which may already counter that;-)
5. Tilting at a windmill: The MUSTs in the section don't help the implementer: s/MUST be used/is used s/MUST maintain/maintains s/MUST restart the time and carry out/restarts the timer and carries out 5.1 Regardless of the type, all Update requests include an 'uptime' field. Since the self-tuning extensions require information on the uptimes of peers in the routing table, the sender of an Update request MUST include its current uptime in seconds in the 'uptime' field. I think in the newspaper business, this is called "burying the lede". The MUST is in the wrong place. What's important is that all Update requests MUST include an 'uptime' field. The MUST in the second sentence makes it confusing as to whether there are choices about other kinds of Updates or different format for time ("Are there other senders that don't have to use 'uptime'?" "Could they send minutes instead of seconds, and you can only use seconds in Updates? Is that why they're saying 'MUST'?" I suggest replacing with: NEW The self-tuning extensions require information on the uptimes of peers in the routing table. The sender of an Update request includes its current uptime (in seconds) in the 'uptime' field. Regardless of the type, all Update requests MUST include an 'uptime' field. END Maybe I'm not understanding how this works, but the laste sentence of this section is confusing to me. Is the rule that if I've got enough space in my data structure for everything I got from my peer *and* what I had in there before, I keep everything? What if there's not enough space to keep everything? Do I trim what I had and add everything I got in the update, or do I trim what I got in the update? 5.2. Therefore, when the self-tuning mechanisms are used, each peer MUST send a periodic Update request only to its first predecessor and first successor on the Chord ring. Again, potentially confusing because you've described the requirement backwards: NEW Therefore, when the self-tuning mechanisms are used, each peer only sends a periodic Update request to its first predecessor and first successor on the Chord ring; it MUST NOT send Update requests to others. END In the last two paragraphs of this section, which of the MUSTs are actual requirements that an implementation needs to be aware of, and which are just statements of the way things are done in the protocol? In other words, why is the following not a reasonable replacement? NEW The neighbor stabilization routine is executed when the stabilization timer fires. To begin the neighbor stabilization routine, a peer sends an Update request to its first successor and its first predecessor. The type of the Update request MUST be 'neighbors'. The Update request includes the successor and predecessor lists of the sender. If a peer receiving such an Update request learns from the predecessor and successor lists included in the request that new peers can be included in its neighborhood set, it sends Attach requests to the new peers. After a new peer has been added to the predecessor or successor list, an Update request of type 'peer_ready' is sent to the new peer. This allows the new peer to insert the sender into its neighborhood set. END If the answer to the question, "Why does it say MUST?" is "Because if you don't do that, you're not doing the protocol", that's going to confuse implementers and can make for brittle code. Please review 5.3, 5.4, 6.1, 6.3, 6.4, 6.5, 6.6 for similar uses. 6.2: The size of the successor list MUST be set to ceiling(log2(N)). An implementation MAY place a lower limit on the size of the successor list. MUST/MAY conflict. I think the first sentence should say "MUST be set to a maximum of". In the last paragraph, change "MAY" to "can".
Probably a very simple question from browsing through the doc (mainly due to my lack of RELOAD knowledge, combined with my laziness to review the 175 page RFC 6940) This document extends the mandatory-to-implement chord-reload algorithm by making it self-tuning. The use of the self-tuning feature is optional. However, when used, it needs to be supported by all peers in the RELOAD overlay network. From an operational point of view, what is the mechanism to discover that all peers support this optional self-tuning feature?
Thanks for a nice write up of security considerations as well as addressing the questions from the SecDir review.
Thanks for addressing all my comments in version -13. The one we're still talking about, now a non-blocking comment, is below: 1. In the Introduction: These characteristics are then used to configure the DHT in a static fashion by using fixed values for parameters such as the size of the successor set, size of the routing table, and rate of maintenance messages. The problem with this approach is that it is not possible to achieve a low failure rate and a low communication overhead by using fixed parameters. Instead, a better approach is to allow the system to take into account the evolution of network conditions and adapt to them. This document extends the mandatory-to-implement chord-reload algorithm by making it self-tuning. Two main advantages of self-tuning are that users no longer need to tune every DHT parameter correctly for a given operating environment and that the system adapts to changing operating conditions. Does this mean that this self-tuning version is intended to be the way chord-reload is implemented in the future? Or is it just meant to be an optional feature, which might or might not be implemented for chord-reload? It seems that self-tuning doesn't work unless most peers support it and share the necessary information. Reply from Jouni: " The self-tuning version is an optional feature. But it needs to be supported by all the peers in the overlay. A RELOAD overlay can either choose to use chord-reload or the self-tuning version." As a non-blocking comment, would it be useful to say what you just told me as part of the text I quote above? I suggest this, which you may accept or decline as you see best (it also inserts a paragraph break for the long paragraph): NEW These characteristics are then used to configure the DHT in a static fashion by using fixed values for parameters such as the size of the successor set, size of the routing table, and rate of maintenance messages. The problem with this approach is that it is not possible to achieve a low failure rate and a low communication overhead by using fixed parameters. Instead, a better approach is to allow the system to take into account the evolution of network conditions and adapt to them. This document extends the mandatory-to-implement chord-reload algorithm by making it self-tuning. The self-tuning feature is optional. When it is used, it needs to be supported by all peers in the overlay. Two main advantages of self-tuning are that users no longer need to tune every DHT parameter correctly for a given operating environment and that the system adapts to changing operating conditions. END
An interesting, good extension based on what looks like lots of research. I wish we had more drafts like this.
I have no objection to the publication of this document. Thanks to the shepherd for noting that softwire had seen the I-D. It would have been good to say why that WG decided not to take this on.
To avoid conflicts with any other network that may communicate with the CLAT or other IPv6 transition solution, a locally unique IPv4 address must be assigned. Maybe I'm wrong, but the sentence above seems to contradict the one below. It is important that a host never enable 2 active IPv4 continuity solutions simultaneously in a way that would cause a node to have overlapping address from 192.0.0.0/29. Also, don't you need a MUST and MUST NOT, respectively, in the two paragraphs?
Thanks for addressing Barry's comment on the Security Considerations question. I'm fine with that just being an operational consideration and that it won't work.
Some non-blocking comments: To the document shepherd: Thanks, Fred, for being clear about the uncertainty of the correct document status for this. This AD, at least, sees no issue with an Informational RFC "updating" a Standards Track one, and thinks this would be fine as Informational. That said, I don't object to Standards Track, and one can certainly say that it's specifying the standard for use of 192.0.0.0/29. So I'll let other ADs argue about this if they want: the status is currently Standards Track, and that's fine with me. I'll note that the "updates" tag at the top is done wrong (it should be "Updates: 6333 (if approved)", with no brackets and no "RFC"). The RFC Editor will handle that, but if the authors happen to put out a revised I-D for other reasons, they might fix that while they're at it. I wonder why it's felt that this updates 6333, and that it doesn't update 6877. It seems to me that the same argument applies to both: you want people implementing either one to be aware that the other might use the same address block, so you want readers of both RFCs to be aware of this change. This is specifying an address range that 6877 is expected to use. The Security Considerations say there's nothing to say, but the paragraph right before that says, "It is important that a host never enable 2 active IPv4 continuity solutions simultaneously in a way that would cause a node to have overlapping address from 192.0.0.0/29." Isn't that a security consideration?
I was wondering the same thing as Barry about the caution against overlapping addresses, although I thought for awhile and failed to come up with a scenario in which having multiple solutions configured on the same address would actually create a vulnerability as opposed to just being broken.
A small point that is not at the level of a Discuss, but... Are there not some implications on the integrity of the message ID on a message that should be stated. Clearly, if a message ID can be touched, the message can be made to appear to be a duplicate causing the sieve to throw it out.
I wondered what'd happen if you used a DKIM-Signature header with this, but I guess it should just work. However, I don't recall if that header value is ok to compare case-sensitive (e.g. "d=" might not be?). I don't think any of your examples show how to do the tolower thing with a header field value, (or is that the default for "set"?) so I guess you could add one that does, but up to you, since I assume the intended readership know this stuff. Nothing to do with this draft in the end, but I think the security/privacy discussion ended up raising a couple of interesting issues that might be worth revisiting if/when someone has energy: those were a) if we could make some good privacy-friendly (but also admin friendly) recommendations about logging mail and b) if we could consider the privacy implications of sieve scripts or other filters (I liked the "stupid boss" folder name one, and am guilty of that for some of my own mail:-) and what those might expose. For (a) I could imagine a useful informational RFC, not sure for (b).
I have no objection to this extension; I think it will be helpful for some folks. Interestingly, I can't see ever using it myself: When I get duplicates from a mailing list, I *always* want the one that was sent from the list, with the List-* header fields on it, and *not* the one sent directly to me. Unfortunately, the one from the list is almost always going to arrive after the one sent directly to me, and the extension doesn't give me enough state to find the message(s) that came in earlier so I can decide which one to keep. But like I said, I can see others using this. As to specific comments: As a side-effect, the "duplicate" test adds the message ID to an internal duplicate tracking list once the Sieve execution finishes successfully. I think this may have been mentioned in response to someone else's comment, but perhaps this should be: As a side-effect, the "duplicate" test adds a unique identifier (again, by default the contents of the Message-ID header field) to an internal duplicate tracking list once the Sieve execution finishes successfully. And then change other occurrences of "message ID" to "unique identifier" elsewhere in the document as appropriate.
Background info: While doing a PC migration, along with an email migration, I found myself in the situation where - I had some duplicate emails in thunderbird - Some of my emails were already manually classified into folders. So it was hard to discover those without redoing the manual classification. This thunderbird add-on , http://removedupes.mozdev.org/, was very helpful to me. Discussing with Stephan Bosch, I understand that Thunderbird add-on is used to remove duplicates from the user's mailbox, after delivery, while this Sieve extension is used to detect duplicates while they are being delivered. This is performed using a persistent duplicate tracking list with unique ID values (typically the Message-ID) of previous deliveries and not by searching the destination folder(s) for messages with a matching ID. The issue with the SIEVE extension is that you have to enable this functionality in advance ... when you know that you're going to do something dangerous. Maybe that works ... but that reminds me of access-list management: "No, I will not do anything stupid! ... oops, I can't access my device any longer!". Or maybe you probably expect this SIEVE extension to be always on? I don't think it's mentioned. Along the same line (and with my use case in mind): Implementations SHOULD let entries in the tracking list expire after a short period of time. I was thinking: "short" = seconds, or minute. So not applicable to my email/PC migration use case. I saw later: A default expiration time of around 7 days is usually appropriate. Good. I like your 4 examples, but the one I was more interested into was: can we send the duplicates into the same folder. That would allow me to troubleshoot the root cause being the duplicates (subscribed to 2 mailing lists, synch issue, redirection, etc.) Bottom line: this draft could be improved by discussing the use cases you have in mind. Certainly not a blocking factor though
Thanks for clarifying my questions in the updated text!
I will watch, with interest, the discussion of Alissa's DISCUSS points.
Thanks for addressing my DISCUSS points. As for protecting scripts/address books in transit, per Ned's email, I would be interested to know if there is anyone interested in taking that work up. Or if not, if we could at least note it somewhere as an outstanding vulnerability -- maybe at https://trac.tools.ietf.org/group/ppm-legacy-review/ (which I can't load right now because the tools site seems to be down, so not sure if that is a good place)?
- section 3, last para: the magic cookie is mentioned here without introduction. Maybe add a ref to section 6 of 5389 if that's the right place? - 4.1.1: "The <host> value MUST be used when using the rules in Section 7.2.2 of [RFC5389] to verify the server identity. A STUN URI containing an IP address MUST be rejected, unless the domain is provided by the same mechanism that provided the STUN URI, and that this domain name can be passed to the verification code." I didn't get that sorry, can you explain what it means? The "domain is provided by" bit confused me. (Same for end of 4.6.1) - 4.2, 1st para: "not possible" hmm. Well, if the same SDP stuff is sent to many places then it is, or if the attacker can otherwise see the SDP stuff. Isn't that common or won't it be common with WebRTC? - 4.2, 2nd para: I'm not getting if you're encouraging folks to use [I-D.thomson-rtcweb-ice-dtls] or not. Might help to be clear about that. (I've not followed the discussion on that draft though.) - Section 5: Thanks!
I do not have any objection to the publication of the draft and this DISCUSS is just a blocker for IANA's ticket #767952 in order to clean up the port registry for STUN and TURN. I will get back with some text proposal for the IANA considerations section.
And one comment, along the lines of Kathleen's comment: transport. But TLS-over-TCP is not an optimal transport when STUN is used for its originally intended purpose, which is to support multimedia sessions. This sub-optimality primarily stems from the added latency incurred by the TCP-based head-of-line (HOL) blocking problem coupled with additional TLS buffering (for integrity checks). This is a well documented and understood transport limitation for secure real-time communications. This HOL text reads weird. HOL is one issue, but the other issue is also retransmissions that are not need for real-time traffic but caused by TCP. Wouldn't it be sufficient to say, independent of TLS, that TCP is well-known not to be the first choice for transport real-time multimedia sessions?
Editorial: Section 4.3 has some broken XML code for the reference.
First of all, let me applause. I don't recall the last time a WG was ahead of schedule. Jul 2014 Send draft adding DTLS as a transport for STUN/TURN to IESG for publication as Proposed Standard draft-ietf-tram-stun-dtls Confused by the abstract/footer. The former is "DTLS for STUN", while the latter is "TURN over DTLS". Both should be aligned. Wouldn't the abstract/footer be more accurate with "DTLS for STUN and TURN" or maybe "DTLS for ICE"?
Thank you for addressing the SecDir review comments. I'll look for the update as many good points were made and discussed with the editors. This is a placeholder to watch for the corrections identified in the review. The discussion looks good so far, thanks. Could a reference be added for the two items in this description of the Introduction? This sub-optimality primarily stems from the added latency incurred by the TCP-based head-of-line (HOL) blocking problem coupled with additional TLS buffering (for integrity checks).
I have no objeciton ot the publication of this document as an RFC, but some comments from the Routing Directorate review by Dimitri Papadimitriou are included below. I agree with these comments and have updated the text with my own queries. You may be able to address these comments with email or small changes to the text. --- Section 4.1 states A gateway or relay implementation does not necessarily require a fully-functional, conforming implementation of IGMP or MLD to adhere to this specification, but the protocol description that appears in this document assumes that this is the case. I am not sure what this statement intends to actually say. Similar statement is made in Section 5.2.1 --- Section 22.214.171.124. Figure seem to imply only PIM-SM can be used? Is this the intention? if so, it might be a good idea to call it out in the text. If not, maybe make clear that the figure is only an example. --- Section 126.96.36.199 Any specific reason to impose a "provider-specific relay discovery mechanism" or "a private anycast address" to obtain access to these relays. What prevents making them "publically accessible"? --- Section 188.8.131.52 The concept of "unicast Relay" and "unicast Relay address" appears for the first time but isn't yet defined. --- Section 184.108.40.206 Means by which the "Relay Discovery Address" is being advertised should be documented or referenced. --- Section 220.127.116.11 point 2 How can the GTW verify that the responder (or the entity responding on behalf of it) is the actually the RELAY it pretends to be? --- Section 18.104.22.168 This section doesn't provide any details concerning timing, error situations (what happens when a message is lost?), and means to overcome such situations. Further down the text (Section 5.2.X/5.3.X) these details are provided so maybe just add a forward pointer. --- Section 22.214.171.124 What is the default setting for the timer mentioned in "Each time the gateway receives a Membership Query message it starts a timer..." --- Section 126.96.36.199 point 3 Expand the acronym QQIC --- Section 188.8.131.52 point 10 Usually one refers to a stream of mcast messages, so does the relay encaspulate messages 1 by 1? What happens if the incoming message is too long to be transmitted towards the gateway? --- Section 184.108.40.206 Where you say "or the relay receives a valid Teardown message from the gateway" please at a pointer to the next section. --- Section 220.127.116.11 The text seems to imply that the message SHALL only be used in the conditions described in that Section, but prevents other usage e.g. sending a Teardown without prior Membership Query/Update message. Is this really the intent? --- Section 18.104.22.168 The philosophy seems to be that a GTW may receive incoming mcast traffic from the Relay after a long waiting period, but in this case all listeners might have "left". How comfortable are you that this type of asynchronous mode will be effective? --- Section 5.1.3 It looks really odd to put the P flag in the middle of the two reserved fields. I can see you intend one byte of flags (with seven flags reserved) and two bytes of pure reserved field. If this was your intent, I think you should label the first reserved field as "Flags" and set up an IANA registry (including allocation policy) for the rest of the flags. OTOH if you want the reserved fields to be completely available for any future use, then perhaps you should put the P flag in bit 8. --- Section 22.214.171.124 Should you be concerned about traffic ordering issues in the exchange between Relay downward to the GTW as there is intermediate processing on both entities? --- Section 6 You say AMT is not intended to be a strongly secured protocol and give the argument to make the protocol light-weight You could enhance the security with minimal cost by including a key (cf. e.g. RFC 2890) in the IP multicast traffic encapsulation format to prevent network relays resulting in unwanted traffic to the end-user. --- Section 6.2 The AMT protocol provides no means for detecting or defending against a man-in-the-middle attack - any such functionality must be provided by multicast receiver applications through independent detection and validation of incoming multicast datagrams. You might at least tell us what action you recommend if the receiver detects such a problem.
I see there's a -17 of this but don't see that it addresses the discuss points below. And I've of course lost the context since January;-) Seems like the TSV area discusses get priority on this one (still;-). (1) I'm not getting the trust model. Why is that "MAC" not the same as a random number chosen by the relay? And that'd be more robust against mobile gateways for example. Even better would be an open-channel DH exchange. I don't understand what the current design gets you. (2) I also entirely don't get why its ok to use a fixed-width 48-bit MAC with a home-grown algorithm based on MD5 and no agility and that page 67 says a relay "MAY skip" sometimes. I'd also suspect the home-grown algorithm specified in 5.3.5 may have weaknesses - the gateway knows or picks all the inputs up to the secret which therefore MUST be long and strong, and side-channel attacks (timing) might be effective against a relay. That all seems far too ad-hoc for a standard when hmac exists and is better. Can you point me at where this has gotten some cryptographic review? (But note the answer to point 1 might impact on this, so bottoming out point 1 first would be best maybe.)
I didn't check if these comments are still relevant for -15 but have left them here just in case. - 11 years. Wow! Kudos for being persistent! - p11, in the figure (my ascii-art sympathies btw;-), why is the application dealing with multicast data via UDP only? - Its not that common to have a field called a nonce and yet have that sent in multiple messages. Maybe this is more a kind of session id? - 5.1.2 - it'd have been nicer to have a length field for the nonce or relay address so that you could vary the nonce length without confusing matters. Seems like there're enough unused bits to do that if you wanted. - 5.1.5/5.1.6: What if the encapsulated packet is bigger than the MTU, isn't that a problem? - 5.1.6: Oughtn't you say something about congestion and being TCP friendly? - Section 6: I always think that trying to be "as secure as <<some insecure thing>>" is a bad goal to select. - A.1 and 5.3.5 show MD5 inputs in different orders. They ought be the same.
I am moving to Abstain, as some issues have been addressed, namely 2 and 3 (partly), but others such as 1) are not addressed and will probably not be solved by this draft. I still do not see that this protocol is safe for operations across the public Internet, as the major point 1) isn't solved. Therefore, I would appreciate very much to emphasize the point "- Limit the scope of this to wallened gardens and adding operational consinderations describing the limits of it." *************************************** The old DISCUSS as reference: I have no general objection to the AMT protocol as such, but the below DISCUSS issues. The overall description of the protocol and its framework is well done. The current AMT protocol has these DISCUSS issues that must be addressed: 1) lack of congestion control of the AMT traffic between relay and gateway -- Then tunnel multicast traffic can exceed a path's capacity. Further, such a relay will send out a number of tunnelled multicast flows to a huge number of destinations, either competing with themselves or with other flows. 2) lack of MTU handling -- There absolutely no mentioning of MTU issues in the draft. However, tunnelled packets can easily exceed the path MTU. How does AMT react to this? 3) Use of zero IPv6/UDP checksum and failure handling, if any middlebox enroute is not allowing zero UDP checksum packets to traverse. This is also a question on what happens, if the traffic is black holed for any other reasons, i.e., when no ICMP error message is returned at all. 4) Security: There is a change in the threat model, i.e., multicast requires LAN access but with AMT almost anybody can access the multicast feed. I can understand that this is not needed in certain deployments, e.g., a mobile phone network, but this is not well documented in any part of the draft. 5) NAT traversal and the IANA-assigned port. Section 126.96.36.199 assumes a simple NAPT with translation from IPv4 to IPv4. However there can be other NATs than even change the source IP address for incoming flows and potentially also the port number. Is there any specific reason to nail down the source port of the relay? The discovery mechanism could also return an arbitrary port number. 6) Section 188.8.131.52.4, start of page 58: NAT timer. The NAT timer is independent of any other time, as this really depends on the NAT on the path. 7) The current AMT specification cuts away the possibility to return ASM receiver feedback to the source. This is not documented nor described. Magnus did an excellent summary of the above points in his review: http://www.ietf.org/mail-archive/web/ietf/current/msg76475.html I can see three potential ways forward for this draft: - Address the above topics to make the draft ready for the Standards Track and thus safely deployable in the public Internet - Reclassify it as experimental and figure out all missing parts. - Limit the scope of this to wallened gardens and adding operational consinderations describing the limits of it.
1. From this figure ... Isolated Site | Unicast Network | Native Multicast | (Internet) | | | | | | Group Membership | +-------+ ===========================> +-------+ Multicast +------+ |Gateway| | | | Relay |<----//----|Source| +-------+ <=========================== +-------+ +------+ | Multicast Data | | | | | Figure 1: Basic AMT Architecture ... I was not sure whether the left part of the gateway was IP unicast of multicast. It's only when I saw the following figure that I understood. Gateway Relay General _____ _____ ___________ Query | | | | Query ___________ | |<------| | | |<------| | | Host Mode | | AMT | | AMT | |Router Mode| | IGMP/MLD | | | UDP | | | IGMP/MLD | |___________|------>| |<----->| |------>|___________| Report | | | | Report Leave/Done | | | | Leave/Done | | | | IP Multicast <------| | | |<------ IP Multicast |_____| |_____| Multicast Reception State Managed By IGMP/MLD It might be better to clarify it earlier in the draft
This is an exceptionally well written document, and was generally easy to understand. Ron, thanks for fixing my DISCUSS point in an RFC Editor note. What remain are a few non-blocking comments. I think that addressing these will make the document a little better; feel free to chat with me about them if you like. -- Section 4 -- This may be implicit in what the paragraph in Section 4 says, and perhaps Sections 4.x and 5.x are entirely consistent and no one will find any errata, but there's a lot here, and just in case there's something we don't catch... ...might it be reasonable to add a sentence such as this to the paragraph in Section 4?: "If anything in Section 4 is inconsistent with or contradictory to something in Section 5, the text in Section 5 is definitive." -- Throughout Section 5 -- You've mostly consistently used the phrase "IANA-assigned AMT port number" to represent port 2268 [Section 7.3]. Mostly, except for the following: 5.1.5 uses "IANA-assigned AMT UDP port number" (adds "UDP") 184.108.40.206.2 uses "IANA-assigned UDP port number" (omits "AMT" and adds "UDP") 220.127.116.11 uses "IANA-assigned port" (omits "AMT" and "number") It's probably useful to fix those three so that all uses are exactly the same. Also, a "(see Section 7.3)" at the first instance, in Section 5.1.1, wouldn't be bad. -- Sections 18.104.22.168.5, 22.214.171.124.6, and 5.3.6 -- These all refer to "a cryptographically secure pseudo random number generator." Would they benefit from an informative reference to RFC 4086? -- Section 5.3.5 -- A Response MAC is produced by a hash digest computation. A Response MAC value is computed from a Request message for inclusion in a Membership Query message, is computed from a Membership Update message to authenticate the Response MAC carried within that message, and is computed from fields in a Teardown message to authenticate the Response MAC carried within that message. I had to read this a few times to parse it correctly. Once I got it, I found that there's nothing wrong with it... but maybe we can make people work less hard this way?: NEW A Response MAC is produced by a hash digest computation. A Response MAC value is computed in three situations: from a Request message, for inclusion in a Membership Query message; from a Membership Update message, to authenticate the Response MAC carried within that message; and from fields in a Teardown message, to authenticate the Response MAC carried within that message. END Gateways treat the Response MAC field as an opaque value, so a relay implementation may generate the MAC using any method available to it. The hash function RECOMMENDED for use in computing the Response MAC is the MD5 hash digest [RFC1321], though hash functions or keyed-hash functions of greater cryptographic strength may be used. Why is this a 2119 "RECOMMENDED"? Is there any reason the *protocol* cares what hash algorithm is used? -- Section 126.96.36.199 -- If a relay supports the Teardown message, it MUST set the G-flag in the Membership Query message and return the source IP address and UDP port carried by the Request message in the corresponding Gateway IP Address and Gateway Port Number fields. If the relay does not support the Teardown message it SHOULD NOT set these fields as this may cause the gateway to generate unnecessary Teardown messages. What reason might a relay have for violating that SHOULD NOT? Why would a relay that does not support Teardown sometimes need to set those fields, such that "SHOULD NOT" (rather than "MUST NOT") is necessary? -- Section 188.8.131.52 -- A relay MUST maintain some form of group membership database for each endpoint. The per-endpoint databases are used update a forwarding table containing entries that map an (*,G) or (S,G) subscription to a list of tunnel endpoints. A relay MUST maintain some form of group membership database representing a merger of the group membership databases of all endpoints. The merged group membership database is used to update upstream multicast forwarding state. A relay MUST maintain a forwarding table that maps each unique (*,G) and (S,G) subscription to a list of tunnel endpoints. A relay uses this forwarding table to provide the destination address when performing UDP/IP encapsulation of the incoming multicast IP datagrams to form Multicast Data messages. I don't really want to pick on these too much, mostly because I can't imagine how *else* you might do this other than maintaining databases/tables, but... Strictly speaking, the 2119 keywords should be calling out protocol requirements, not implementation methods. It seems that the requirements are actually in the second sentence of each paragraph, and the MUSTs should be attached to those. I'll use the second one as an example; perhaps this?: NEW-maybe A relay MUST be able to update the upstream multicast forwarding state [a little more is needed here]. This is typically done by having the relay maintain some form of group membership database representing a merger of the group membership databases of all endpoints. END I would prefer it if you could re-cast each of these three paragraphs to attach the MUST to the actual protocol requirement, and talk about databases and forwarding tables as exemplary implementations (rather than attaching the MUST to the implementation). That said, I'll remind you that this is a non-blocking comment, and if you think it will make the spec more awkward or less clear, then please don't do that.
While I'm happy to work to document or ameliorate the Transport area's concern that unicast encapsulation is not sensitive to to congestion control, fundamentally multicast encapsulation never has been. While some applications that leverage multicast are adaptive to loss most are not. AMT doesn't really change that situation.
- section 4: Surely this is badly stated: "SIP messages transported over both a plain and secure WebSocket connection can be completely and uniquely represented by appropriately setting these two flag fields." I read that as saying that two flags can uniquely represent a specific message.
The document shepherd actually got one bit incorrect: This is simply a registration in a registry that only requires "IETF Review", not "Standards Action", so Informational would be perfectly appropriate for this document. It's never going to advance to Internet Standard, and I see no particular reason to have another Proposed Standard hanging around, so we should just make this Informational (which we can simply do on the call). I'm certainly not willing to hold things up if anyone objects, but it seems like a reasonable thing.
Am I correct that this document doesn't update RFC 6872, because it only adds a new value for the "Transport Flag" field (as opposed to a new field), and therefore the information model is not updated? From idnits: -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235)
-- Section 1 -- The HTTP reference needs to change to RFC 7230. -- Section 5.1 -- A tiny point: it seems to me that the code snippet would be better in an appendix, referred to from here and from Section 5.2. It seems an unnecessary distraction here. -- Section 6 -- The string "draft-ietf-sipcore-sip-websocket" is a vestige, and should now be "RFC 7118". Better, though, more useful, would be a change such as this: OLD Any security considerations specific to the WebSocket protocol or its application as a transport for SIP are detailed in the relevant specifications (RFC 6455 [RFC6455] and draft-ietf-sipcore-sip- websocket [RFC7118]) and are considered outside the scope of this document. NEW Any security considerations specific to the WebSocket protocol or its application as a transport for SIP are detailed in the relevant specifications (the WebSocket potocol [RFC6455] and SIP over WebSockets [RFC7118]) and are considered outside the scope of this document. END -- Section 7 -- The reference document for the IANA registration shouldn't really be this document, as this document doesn't say much. The right reference is RFC 7118, where people who want to understand SIP over WebSockets need to go. Or, if you prefer, you can list both documents ("[RFC_XXXX_], [RFC7118]").
The draft seems okay, although I'd like to know why there isn't a stronger requirement around replay protection. The Security Considerations section says: Because of this, implementers must be careful in how they use information obtained from these possibly- replayed messages. For example, information from unsecured messages should not be used to modify any stored information obtained from secured messages. and section 7.4 provides a way to do this with a challenge: The recommendations in [RFC4086] apply with regard to generation of the challenge value. The byte string MUST be at least 4 bytes in length and a new value MUST be chosen for each Challenge TLV transmitted. An important part of replay protection is determining if a newly-heard neighbor is actually present or is a set of recorded messages. This is done by sending a random challenge value to the neighbor and then receiving that same value in a Response TLV sent by the neighbor.
I have a couple of questions about the use of 2119 "MAY" below; I think it's important to resolve them, so please consider these comments. -- Section 8 -- Update messages MAY be sent as above, or MAY be sent to a site-local all- MLE-nodes multicast address (to be assigned by IANA). Or they may be sent in any other way, as those "MAY"s specify optional behaviour -- so you MAY also do neither. Is that the intent? Or is the intent that one can choose, at one's option, between those two choices, but no other? If that's what's meant, let me suggest this instead: NEW Update messages MUST either be sent as above, or be sent to a site-local all-MLE-nodes multicast address (to be assigned by IANA). END What is the line that says "MAX_RESPONSE_DELAY_TIME 1 second" meant for? Should there be some other text around it? Similarly for the table: should the previous paragraph have an additional sentence that says, "The following are recommended default values for relevant timeout and retransmission parameters."? I think this would read better with an explanation such as that. -- Section 10 -- If large numbers of Link Request messages arrive a device MAY reduce or completely suspend sending Link Accept messages, and MAY send Link Reject messages instead. This is a similar double-MAY to the previous one, and it brings up a similar question: as written, it says: 1. If large numbers of Link Request messages arrive, a device has the option of reducing or completely suspending sending Link Accept messages. 2. If it does that, it has the option of sending Link Reject messages instead. It also has the option of not sending Link Reject messages instead. It could, for example, not respond at all, or respond in some other way. Is that what's intended? Or is it intended that if it stops sending Link Accepts, it will always send Link Rejects? If so, then just removing the second "MAY" will fix it.
I have no objection to the publication of this document, but there are some points that need work... 1. In section 6, it is unclear as to how Command Type 2 differs from a combination of Command Types 0 and 1. In what instances would a sender use Command Type 2? It seems to me that this *could* be an exchange like: 1) A sends CT==0 to B, 2) B sends CT==2 to A, and 3) A sends CT==1 to B. Is that the expected usage? If so, it should be explained. I was expecting to see Section 10 do that, but that didn't materialize. 2. Some of the specified Command Types and TLVs are obviously link-local in nature. Are there Command Types and TLVs that are only network-wide? I would like to see some description of how far each of the Types and TLVs should be propagated. 3. This is related to Barry's comment about destination address selection. Section 8 should tighten up the guidance on address selection. This should be tied to the point raised in #2 above, in that the destination address needs to take the scope of the information contained in the message into account. 4. It is unclear to me what Section 9 is saying about "reserved Command Types" and "reserved TLV Types". Are those just values that are not recognized?
- 1.2: saying one should log stuff is probably right here. However, it'd also be good to say something about protecting those logs, (access to which could expose various things) and about periodically flushing them for privacy reasons if that's not elsewhere. Just a sentence or two would probably be fine. - 2.4.1: I think the "pretty much useless" statement about IPsec reads as if biased, which doesn't seem right. One could argue that malware can benefit just as much as an IDS from snooping on packets for example, even if that is nowhere near as common today. Fixing the language in that paragraph would be good so that it doesn't have to be changed if malware migrates over time from end hosts to e.g. the routers and switches within an enterprise network. - 4.3: is the text about smartphone support for IPv6 still accurate? I don't know that its not, but it does read as if written some time ago. - 4.3: I wondered why there are no recommendations about printers specifically when those only support IPv4. Is there nothing to say about discovery there? I don't know that there is but would have thought it possible. - 4.4: would have thought that specific mention of web proxies would be useful here - locally, we've had issues with those even after mail all works fine. - The secdir review spotted a few nits.   https://www.ietf.org/mail-archive/web/secdir/current/msg04843.html
Overall, this is a very helpful draft, thanks for taking the time to do it. I spotted similar things to Stephen and agree on the point of adding some mention of logging as well as log protecting. I think there should also be mention in section 3.3, monitoring for external networks in addition to the earlier section Stephen referenced. In case it is helpful for section 3.3 & 3.4, this would apply to the network (filters) as well as to servers and applications, not just firewalls. Nit: first use of CDN in section 6.1 isn't spelled out.
Just a few non-blocking comments... 1. Section 2.1 takes a little too much time describing how the champion and project manager should run an IPv6 project. I think this takes away from the key message of "plan ahead of time". 2. In Section 2.3, it is unclear if the training is meant for everyone in the organization or just those staff members responsible for managing/maintaining the network and the connected equipment. 3. Section 2.6 contradicts some entities approach of shrinking subnets to the smallest possible size in order to preclude rogue devices from attaching and obtaining an address.
I was thinking some of the same things as Stephen regarding logging and IPSec.
tom taylors review for the record. I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the operational area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Revision reviewed: draft-ietf-v6ops-enterprise-incremental-ipv6-05 Summary: The Gen-Art review by Robert Sparks was noted. In the light of that review it did not seem worthwhile to make further editorial comments (but I'm sure the RFC Editor will propose changes in a number of places). Some minor substantive comments are given below. ID Nits: complains about use of RFC 2119 capitalization without a corresponding incorporation of the RFC 2119 boilerplate. A number of the references need updating. Comments: 1. In Section 2.2.1, the implicit assumption is that IPv6 readiness is a binary condition, rather than an accumulation of features that the IETF is still trying to adjust. The authors may wish to warn administrators that they cannot necessarily take vendors' assessment of IPv6-readiness at face value, because definitions of that state may vary. Instead, the administrator needs to develop a checklist of elements of IPv6 implementation, and eventually will need to verify that these elements are functioning correctly, beginning in the vendor's lab if the IPv6 capability is not already present in the field. 2. While smartphones and tablets are addressed explicitly in Section 4.3, they are not mentioned in the lists of equipment given in the introductory sections 1 and 4. Just a suggestion that they be mentioned, perhaps as "mobile devices", so the reader doesn't get the impression that the advice in the document is dated. 3. Meta-comment: The hidden issue in Section 4.1 is the desire of enterprise administrators to control host configuration using DHCPv6 for security reasons, vs. the determination of a blocking plurality of IETF participants to reserve some configuration (e.g., default route) to basic IPv6 mechanisms only. IESG members who have not followed discussions of this topic should be aware that they were extensive, did not end in consensus, but did provoke expressions of frustration from enterprise-oriented operators, of the nature of: "Why should we bother to be here if you won't listen to us?". Tom Taylor
I certainly agree there's nothing here conflicting with IETF work. I presume that the ISE is trying to be cognizant of whether this conflicts with W3C work.
This is related to earlier http-patch and json-patch work, and borrows from those. It's not in conflict with anything going on now, and it's gotten a review on the media-types list.