IESG Narrative Minutes
Narrative Minutes of the IESG Teleconference on 2014-07-10. These are not an official record of the meeting.
Narrative scribe: John Leslie and Susan Hares (The scribe was sometimes uncertain who was speaking.)
Corrections from: (none)
1 Administrivia
2. Protocol Actions
2.1 WG Submissions
2.1.1 New Items
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
2.1.2 Returning Items
Telechat:
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:
Telechat:
3.1.2 Returning Items
3.2 Individual Submissions Via AD
3.2.1 New Items
3.2.2 Returning Items
3.3 Status Changes
3.3.1 New Items
3.3.2 Returning Items
3.4 IRTF and Independent Submission Stream Documents
3.4.1 New Items
3.4.2 Returning Items
1229 EDT no break
4 Working Group Actions
4.1 WG Creation
4.1.1 Proposed for IETF Review
Telechat::
Telechat::
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
Telechat::
Telechat::
Telechat::
7. Agenda Working Group News
1251 EDT Adjourned
(at 2014-07-10 07:30:02 PDT)
draft-ietf-ppsp-peer-protocol
In this text: 3. Messages In general, no error codes or responses are used in the protocol; absence of any response indicates an error. Is there accurate qualifier more narrow than "in general" that you could substitute? In a quick scan, the only other instances of "error" are "ICMP error", so maybe you don't need a qualifier at all? In this text: 3.1. HANDSHAKE After the handshakes are exchanged, the initiator knows that the peer really responds. Hence, the second datagram the initiator sends MAY already contain some heavy payload, e.g. DATA messages. To minimize the number of initialization round-trips, the first two datagrams exchanged MAY also contain some minor payload, e.g. HAVE messages to indicate the current progress of a peer or a REQUEST (see Section 3.7), but MUST NOT include any DATA message. This was difficult for me to parse, and the words "heavy" and "minor" didn't help me understand. Is this saying something like "Peers don't include DATA messages in payloads they send unless they've akwa successfully exchanged messages"? If that's not what's meant, is there a list of "heavy" and "monor" messages? (Obviously, I don't think the MAYs are 2119 MAYs because they are so imprecise, but that's another story) I should also mention that "heavy" appears 10 times in the specification, and I don't think it's ever defined. Is this a term famliar with those schooled in the art? In this text: 3.2. HAVE In particular, whenever a receiving peer P has successfully checked the integrity of a chunk, or interval of chunks, it SHOULD send a ^^^^^^ HAVE message to all peers Q1..Qn it wants to interact with in the near future. A policy in peer P determines when the HAVE is sent. P may sent it directly, or peer P may wait until either it has other data to sent to Qi, or until it has received and checked multiple chunks. This wasn't clear to me. I'm not understanding why a SHOULD is appropriate, but I suspect I shouldn't be askig a 2119 question, because this is tangled between "send a HAVE to the peers you want to interact with in the near future" and "if you don't want to interact with a specific peer in the near future, you can wait to send a HAVE". Is that even close? In this text: 3.4. ACK ACK messages MUST be sent to acknowledge received chunks if PPSPP is run over an unreliable transport protocol. ACK messages MAY be sent if a reliable transport protocol is used. In the former case, a receiving peer that has successfully checked the integrity of a chunk, or interval of chunks C MUST send an ACK message containing a chunk specification for C. As LEDBAT is used, an ACK message MUST contain the one-way delay, computed from the peer's current system time received in the DATA message. A peer MAY delay sending ACK messages as defined in the LEDBAT specification. (I emphasize that this is a question, not even a comment) How hard did the working group fight to pick a single style of transport protocol for PPSPP, rather than support multiple styles that don't use the same state machine? If that decision got good discussion, fine, but I wanted to ask because support for both reliable and ureliable transport adds complexity, and I've seen working groups that tried to do transport-independent protocols only because they thought that's what the ADs expected. In this text: 5.3. The Atomic Datagram Principle As explained above, a datagram consists of a sequence of messages. Ideally, every datagram sent must be independent of other datagrams, so each datagram SHOULD be processed separately and a loss of one datagram must not disrupt the flow of datagrams between two peers. Thus, as a datagram carries zero or more messages, neither messages nor message interdependencies SHOULD span over multiple datagrams. This principle implies that as any chunk is verified using its uncle hashes the necessary hashes SHOULD be put into the same datagram as the chunk's data. If this is not possible because of a limitation on datagram size, the necessary hashes MUST be sent first in one or more datagrams. As a general rule, if some additional data is still missing to process a message within a datagram, the message SHOULD be dropped. With that many SHOULDs, I'd be worried that implementations using PPSPP can't count on much. If I receive a message that spans multiple datagrams (even though it shouldn't), that don't include the necessary hashes (even though it should), and I don't drop a message with missing data (even though I should), is that all fine? In this text: 5.4. INTEGRITY Messages Concretely, a peer that wants to send a chunk of content creates a datagram that MUST consist of a list of INTEGRITY messages followed by a DATA message. If the INTEGRITY messages and DATA message cannot be put into a single datagram because of a limitation on datagram size, the INTEGRITY messages MUST be sent first in one or more datagrams. Is this assuming that the path between peers will never reorder packets?
I have a number of discuss points (sorry;-), but most of 'em are pretty simple really. (1) 3.10: What is a "benign" environment? I actually do understand what is meant, but how could a program evaluate that in order to decicde whether or not to send a PES_RESv4? You then refer to a "potentially hostile environment" which could presumably be anywhere, so are you really saying that PES_REScert is the "right thing" to do, but you know it won't be done so these are weasel words around that awkward fact? (Apologies if I'm wrong on that, but that's the impression I got when reading this, but maybe that's just my paranoia:-) (2) 6.1.2.2: What exactly are the "munro" bytes that are the first input to the signature? Where are those defined? (Sorry if I missed/skipped over that;-) (3) 7.6 and 13.5: SHA1 as the MTI is wrong. Why is that ok, given the collision resistance is less that designed for? 7.7 also calls for SHA256 being implemented in any case. The run-time argument in 13.5 does not convince me. Attacks only ever get worse, so the collision resistance property which this protocol needs ought lead to selection of an as-far-as-known good hash function. Today that means SHA256 and not SHA1. (4) 7.7: Why RSASHA1 and not RSA with SHA256? (5) 7.10: The message number is wrong in the figure. (6) 8.4: I don't see the swarm's metadata record in the ascii art diagram and you just say "look at section 7" so two questions: a) where is the "chunk size used" option in section 7? and b) do all the swarm metadata options have to be sent each time with no limit on ordering except as given in section 7 (which had one such order sensitive limit I think)? (7) 8.13: Don't you need to register the ppsp URI scheme? In case its useful, which I doubt, if you have code: RFC6920 URIs could be used for this if you wanted and would save you adding ppsp to the IANA URI scheme registry (and having to deal with the URI police:-) (8) 13.4: Wouldn't DTLS change the chunk size considerations and also influence how messages map to datagrams? Isn't more specification needed to say how to really use DTLS here? Just saying "use DTLS or IPsec or higher layer crypto" doesn't really seem sufficient. And doing the DTLS bits right shouldn't be very hard either.
- Kathleen has the secdir review point covered. - overall comment: This is too long. - The elephant is in the room, but not the intro:-) Surely some comparison with BT is needed in the intro? The first reference is in 3.7 on p13, which just seems wrong. If this is somehow inspired by BT (can't recall) then maybe say so and add a quick sketch (2-3 sentences) on how this differs from BT. Those would really help the reader IMO. Note that this could be done by reference. - 1.1: I really dislike the term self-certification as its quite misleading. I guess its probably too late to get rid of that but what (I think) is going on here is really naming chunks so that if you know the hash of the entire content you can verify that the chunk is from that. (CHECK!!!) - 1.3, 'content': s/asset/file/ would be better I think and less capitalist;-) The term asset is odd here anyway. Same elsewhere. (But note this is really nitty, no need to change unless you want to.) - 3: I don't get what is meant by this "an external storage mapping from the linear byte space of a single swarm to different files" I can sorta see what's meant, but am not sure. Maybe try clarify? - 5.3, last para: Is the 1st MUST there really implementable in general? I think the MUST might be to include those hashes that the sender thinks the receiver needs. - 6.1 - this defines two methods yet says "If the protocol operates in a benign environment the method MAY be used." Which is meant here? - 6.1.2.1: what if different folks think NCHUNKS_PER_SIG has different values? How do we all agree on a value? (BTW, the last sentence of this section is a cool thing.) - 7.4: "In other cases a peer MAY include a swarm identifier option, as an end-to-end check." That's not clear to me, what other cases? - 7.6: I don't get why you need so many options here. Do you really? SHA1 is probably only needed for legacy stuff (is there any of that?), and SHA256 should be fine for everything else. - 7.8: The width of the figure seems wrong. - 7.10: An example compressed encoding would be useful. - 8.16: "perfectly detected" - huh? what does that mean?
The authors have an updated draft ready which addresses IANA's concerns. The updated draft will be posted after the 7/10 IESG telechat. Here is the text proposed by IANA: OLD: IANA is to create the new registries defined below for the extensibility of the protocol. For all registries, assignments consist of a name and its associated value. Also for all registries, the "Unassigned" ranges designated are governed by the policy 'IETF Review' as described in [RFC5226]. NEW: This document is to create a new top-level registry called "Peer-to-Peer Streaming Peer Protocol (PPSPP)", which will host the six new sub-registries defined below for the extensibility of the protocol. For all registries, assignments consist of a name and its associated value. Also for all registries, the "Unassigned" ranges designated are governed by the policy 'IETF Review' as described in [RFC5226].
There has not been a response to Christer Holmberg's Gen-ART review. Do the authors have a view on the questions he asked? For what it is worth, when I read sections 8.14 and 8.15 they do not give as precise instruction for the implementer about how to handle keepalives and dead peer detection as I’d personally like to see. Perhaps a sentence could be added to explain what a node does (or stops doing) when it declares a peer dead.
My DISCUSS here is based mainly on the readability of the document, which seems bad enough to be an impediment to interoperability. As far as I can tell, this document does not define a protocol, in the sense of a set of actions required to achieve a given objective. Instead, it presents a pile of piece parts with a couple of combinations, and notes that these combinations could be used to achieve, e.g., live streaming. (In the language of patents, it has not been "reduced to practice".) What are the steps an implementation follows to join a swarm? To connect to a new peer and request chunks? The pieces seem to be here, but the big picture is completely absent.
"In general, no error codes or responses are used in the protocol; absence of any response indicates an error." -- This made me do a bit of a double-take. Obviously, the requesting peer should timeout if the responding peer doesn't respond, but are there really no cases where the responding peer knows there's a problem and wants to report it? It seems like the CHOKE message is an indication of this sort.
I am still reading this draft, but don't see any response to the SecDir review that raised some very important points for discussion: http://www.ietf.org/mail-archive/web/secdir/current/msg04879.html I'll amend this when I get further into my review and would appreciate a response to the SecDir review. Thanks!
Nice work. This is a well written document, and what looks like a solid protocol. General question on the chunking: Is it the case that a given piece of content is chunked in a specific way, with known chunk IDs, such that every peer that's serving that content up (at least in the same swarm) uses the same chunks with the same chunk IDs? One can guess that from the way things work, but shouldn't the document say that? Or does it, and I missed it? -- Section 3.7 -- When peer Q receives multiple REQUESTs from the same peer P, peer Q SHOULD process the REQUESTs in the order received. What happens if it doesn't? Is there an interoperability issue here? A performance issue? Or what? (That is, why is this a 2119 SHOULD?) -- Section 5.3 -- Thus, as a datagram carries zero or more messages, neither messages nor message interdependencies SHOULD span over multiple datagrams. The negatives in this sentence really make the SHOULD a hidden SHOULD NOT, and its meaning is unclear. I think it would be clearer if it were worded that way: NEW Thus, as a datagram carries zero or more messages, both messages and message interdependencies SHOULD NOT span multiple datagrams. END -- Section 12.1.1 -- Nit: "setup" is a noun; "set up" is a verb. In these two sentences, "setup" should be changed to "set up": A content provider wishing to use PPSPP to distribute content should setup at least one PPSPP server. In addition, a content provider should setup a tracking facility for the content by configuring, for example, a PPSP tracker
In general, I found this draft very clear and understandable. I do understand Richard's discuss that the specific message send-responses aren't given concisely, but I think it is understandable. In Sec 4.2, section after Figure 2: Please s/chunk 0..3/chunk C0..C3 and s/chunks 0 and 1/s chunks C0 and C1 This is just because I had to read it 3 times to stop being confused between the bin numbers and the chunk numbers, so I'd ask for consistency. In Sec 5.2, first paragraph: Please change "For chunk C4 its uncles are nodes 13 and 3, marked with * in the figure." to "For chunk C4 its uncles are nodes 13 and 3 and its sibling is 10; all marked with a * in the figure." In Sec 7.8, the bit figure only goes to bit 12 instead of bit 16 - but the range of CAM and the length listed is 8. In Sec 7.9, can you please add a reference to Table 6 where appropriate? Sec 8.1: typo: mebibyte Sec 8.1: The paragraph on PLPMTUD is a bit confusing. Presumably this is between two peers - but the chunk sizes used by the swarm would be specified by the initial seeder. Thus I can see the PLPMTUD variant being useful to decide upon the PPSPP datagram size, but not the chunk size. Could you please clarify either what I'm missing? Sec 8.13: typo in first line: s/PEX_RES/PEX_RESv4
I'm a little surprised about the choice of LEDBAT for congestion control of live streams. It seems like LEDBAT is not what the receiver would want the sender to use for live-streamed content, because if a bottleneck is encountered on the path, the live stream will yield early, and the recipient's perception of quality will degrade. If the bottleneck is near the recipient, then every sender sending chunks will yield early, and there may be no senders available to stream at an acceptable level of quality. I'm assuming the WG discussed this -- it would be helpful to understand why a more aggressive congestion control was not selected for live streaming.
Section 1.3: "Either a live transmission, a pre-recorded multimedia asset, or a file." What is the difference between a multimedia asset and a file? Also, the term "content asset" is used in a bunch of places in the document, which makes this definition a little more confusing. Section 4.3.1: "When a receiving peer has successfully checked the integrity of a chunk or interval of chunks it MUST send a HAVE message to all peers it wants to interact with. The latter allows the HAVE message to be used as a method of choking." What does "the latter" refer to?
draft-ietf-straw-sip-traceroute
- I support Kathleen's discuss. The potential DoS vector here ought be described as should mitigations and maybe it ought even be limited e.g. via defaults on e.g. the duration for which media is sent. - Almost certainly not worth a mention bnt this could be a nice covert channel if I had a UAS or B2BUA under my control. - Can't SIP requests be forked? What happens if two B2BUAs answer the INVITE with media? - I guess different B2BUAs or different numbers of such could be involved each time you increment the counter, e.g. because of load balancing or odd routing or call forwarding etc. I don't think that's called out explicitly but I guess that's probably fine and you just accept that traceroute can throw up oddities like that. - (Almost a discuss) Why "SDP based on [RFC6849]"? That seems very imprecise, esp if there is any ambiguity in 6849 (which I don't know). - Who hangs up the test call? Is it ok for the UAC to have the previous one still active when incrementing the counter and starting the next one? - The secdir review [1] raised some issues but got no response at all. [1] https://www.ietf.org/mail-archive/web/secdir/current/msg04875.html
In support of Kathleen's and Benoit's issues!
There has been no response to Meral's Gen-ART review. I think we should finish that discussion before approving the document.
Thinking some more about this... I have some questions: I'm not sure who can initiate this traceroute. Everybody? Exactly like a normal traceroute, the output provides a potential attacker useful information on potential targets (this is not mentioned in the security considerations section) As you wrote "Answering media-loopback calls in a B2BUA consumes resources on the B2BUA", so will it lead to an equivalent feature as "control plane policying" for B2BUA in the future? OLD: A mechanism to perform media-loopback test sessions has been defined in [RFC6849], but it cannot be used to directly to test B2BUAs because typically the B2BUAs do not have an Address of Record (AoR) to be targeted, nor is it known a priori which B2BUAs will be crossed for any given session. NEW (removed "to"): A mechanism to perform media-loopback test sessions has been defined in [RFC6849], but it cannot be used directly to test B2BUAs because typically the B2BUAs do not have an Address of Record (AoR) to be targeted, nor is it known a priori which B2BUAs will be crossed for any given session. OLD: The originating UAC can then generate another INVITE to the same target AoR with a Max-Forwards header field value of 1, which will reach the second SIP, and so on. NEW: The originating UAC can then generate another INVITE to the same target AoR with a Max-Forwards header field value of 1, which will reach the second SIP next hop, and so on. Or NEW (not too sure what's the best: The originating UAC can then generate another INVITE to the same target AoR with a Max-Forwards header field value of 1, which will reach the second SIP B2BUA, and so on.
In reading through the security considerations, I'd like to know if there are possible DoS or other attacks that are made more likely by identifying hops along the path and that they respond to these requests? If so, could you add some text on that?
The missing reference to RFC 3261, which was called out in the shepherd writeup, hasn't been fixed (we do need to make it clearer that the shepherd is supposed to see that the "nits" (which aren't all nits, really) are fixed, not just tell us about them). As I don't know whether it's meant to be a normative reference or not, this DISCUSS is here to make sure the reference gets added.
I agree with some of the points already raised. The RFC Editor will switch the Introduction and Terminology sections, to make the Introduction be Section 1. I don't know how flexible they are about that ordering, but if you have a strong reason to have them ordered as they are, there should be an RFC Editor note explaining why.
I will be interested in the answers to the questions raised by Kathleen and Benoit.
draft-ietf-mmusic-rtsp-nat
- I slightly disagree with Kathleen's discuss. NAT logs within enterprises are useful for n/w management reasons, but I'm not sure that extends to public Internet cases at all, where such logs will be huge and potentially quite privacy invasive. (Yes, they maybe required by local legislation but that's different and not really our concern.) I'd hope that text resolving the discuss properly takes both aspects into account. Privacy and log flushing does get a mention but I'd emphasise it more and maybe consider that difference between enterprise and public Internet use-cases. - I don't recall RTSP 2.0 security well enough, but was a bit surprised to not see any mention of (D)TLS for media content here. Can you say why that's not needed?
Two issues in the IANA section, otherwise a fine document: 150: The 150 response code indicates that ICE connectivity checks are still in progress and haven't concluded. This response SHALL be sent within 200 milliseconds of receiving a PLAY request that currently can't be fulfilled because ICE connectivity checks are still running. Subsequently, every 3 seconds after the previous sent one, a 150 reply SHALL be sent until the ICE connectivity I am not sure why the IANA section contains normative language that is important for the implementer, e.g., the above 200 milliseconds. Further the status codes of RTSP 2.0 have usually a short text description called "Directionalty" (which is odd by the way in the registry). 480: The 480 response code is used in cases when the request can't be fulfilled due to a failure in the ICE processing, such as all the connectivity checks have timed out. This error message can appear either in response to a SETUP request to indicate that no candidate pair can be constructed or to a PLAY request that the server's connectivity checks resulted in failure. Can't this be shortened to a truly meaningful error description? And also saying somewhere in the text when this error code should be used, instead of having this in the IANA considerations?
The draft looks good, I just have a question to discuss to see if some additional text is needed for the security considerations section. I don't see any mention of logging and maybe I missed something, if so, please let me know. Since NAT is supported, logging of the NAT translation would be helpful for analysts. Analysts will need to be able to map sessions when investigating possible issues where the NAT happens. Protection of those logs would be helpful as well and should consider log integrity, privacy protection, and purging logs occasionally (retention policies, etc.). Also, logging of connection errors and other messages established by this draft may also be important. Thanks.
Nice, clear document, and what looks to be good technology. Thanks for this. I have a number of non-blocking comments that I'd like you to consider. I'm happy to chat about any of them, if you like (particularly the ones that are not marked as "Editorial"). There's no need to respond to any you agree with, and thanks in advance for considering them. -- Section 4.2 -- I like the way you show the source for the ABNF items that are defined elsewhere. I think I'll remember that, and use it myself. Editorial: Note, the syntax allows multicast addresses, but they SHALL NOT be used in this context. Entirely your option here, but I think it would be better to word this positively, as "This context MUST have a unicast address for this parameter, even though a muticast address would be syntactically valid." An IP address SHOULD be used, but an FQDN MAY be used in place of an IP address. (I think I'm going to give this comment a number, so I can say "Comment #27".) MAY can't be used this way, as an alternative to SHOULD: MAY says that something is completely optional, and that's not what you mean here. What I'd like to see is something that explains why you might not use an IP address, despite the SHOULD... and then says that the alternative for those cases is an FQDN, but without the 2119 key word. Something like this: An IP address SHOULD be used, but [in situations such as X or Y], it could be necessary to use an FQDN instead. -- Section 4.3 -- Editorial: The ICE password and username for each agent needs to be transported using RTSP. The subject is plural, so the verb should be too: "need". -- Section 4.5.1 -- I see that ICE doesn't itself specify any sort of keep-alive responses for the connectivity checks. Here, without advice to the client, I worry about clients that are too strict about checking the timing of the responses. A server sending a response 200 ms after receiving a request does not translate into a client receiving the response within 200 ms of having sent the request. If network delays mean that the response gets to the client after 250 ms, or 300, or whetever, and the client has set a 200 ms timer based on this section, there'll be a problem, no? Similarly for the 150 ms time for the subsequent keep-alives. Should this say something about that? -- Section 6.10 -- Editorial: Both server and client MAY free its non selected candidates Another case of a plural subject: make it "their non-selected candidates" (with hyphen). In the second paragraph, "respectively" needs commas around it (one before, one after). "Client's" should have the apostrophe removed. "Thus" needs a comma after it. -- Section 6.11 -- Editorial: This is important as normally RTSP play mode sessions only contain traffic from the server to the client so the bindings in the NAT need to be refreshed by the client to server traffic provided by the STUN keep-alive. Please add a comma after "important", and hyphens in "client-to-server". -- Section 6.12 -- ICE restarts may be triggered due to changes of client or server attachment to the network, i.e., changes to the media streams destination or source address or port. Is "changes to the media streams destination or source address or port" an exhaustive list? If not, you should change "i.e.," to "such as". Most RTSP parameter changes would not require an ICE restart; instead existing mechanisms in RTSP for indicating from where in the RTP stream they apply is used. I can't parse this; it looks like there's a word missing, or maybe it's just that the structure is awkward. Maybe this?: NEW Most RTSP parameter changes would not require an ICE restart, but would use existing mechanisms in RTSP to indicate from what point in the RTP stream they apply. END OLD Even if otherwise not supporting SETUP during PLAY state for other purposes, the server SHALL support SETUP requests in PLAY state, as long as the SETUP changes only the ICE parameters, which are: ICE- Password, ICE-ufrag and the content of ICE candidates. NEW Even if the server does not normally support SETUP during PLAY state, it SHALL support SETUP requests in PLAY state for the purpose of changing only the ICE parameters, which are ICE-Password, ICE-ufrag, and the content of ICE candidates. END -- Section 7.1 -- A "media-handling proxy" needs a hyphen. -- Section 7.2 -- Editorial: "Signalling-only proxy" should have that hyphen in there. Please add it in the three places that "signalling only" appears. Also, the first paragraph has the two words not capitalized, and the second paragraph has them both capitalized. Please pick one way or the other. (The section title should leave both words capitalized, regardless, because that's what we do in section titles.) -- Section 7.3 -- Editorial: A "media-handling proxy" needs a hyphen; "non-media-handling proxy" needs two hyphens. There are several instances of both in this section. -- Section 11.1 -- To protect against the attacks in ICE-based on signalling information RTSP signalling SHOULD be protected using TLS to prevent eavesdropping and modification of information. This doesn't parse. I think you mean this (but tweak it differently if I didn't get it quite right): NEW To protect against attacks on ICE based on signalling information, RTSP signalling SHOULD be protected using TLS to prevent eavesdropping and modification of information. END
Yet more variation on ice that said it appears to be suitable to task. If someone wanted to write a draft that stated that the IETF is sufficiently bad at nat traversal that it should not be pursued here I would totally sponsor that.
draft-ietf-eman-energy-monitoring-mib
I'm going to pile on to the privacy point raised by Alissa. It's not common to put on another discuss in cases like that but I'm asking to talk about another part of that same topic. As with others, I think these issues may affect more than one document here so we should consider them for the full eman wg output and even broader (for my point 2) and not just for one document. (1) I think this MIB is for a device that wants to tell the world all about its power consumption. Perhaps that is just not suitable for a device where the owner would prefer to be more discrete. Did the WG consider how to structure a MIB for that latter case? For example, is there any way to tell a device (via SNMP) that I am in fact such a privacy sensitive user and would prefer the device to be discrete, and e.g. aggregate measurements over much longer periods or report less fine grained values generally? If there is no such mechanism, why not? (2) On MIB privacy boilerplate: it is not clear to me that boilerplate is really the right thing here - one common way to handle privacy concerns is data minimisation which here could map to not exposing an element or to only exposing aggregate information rather than fine grained values. Those are things that have to be thought about by the MIB developers and can't just be handled via current SNMP security since once the data is out there the privacy breach has happened. (This point is broader than the eman WG of course so more for the AD and MIB doctors.)
I support Alissa's discuss, but am wondering if the proposed text should also include security considerations in addition to privacy if the home use case is mentioned. In addition to revealing privacy information, protections for IoT devices accessed in the home may need to be called out specifically. The current section does call out the need for authenticated access and the use of SNMPv3 to provide adequate security for read/write and read/create functions. How practical is this for the home? Not sure, but warnings on this use case could be helpful in the long run to push for SNMPv3 support for devices used in the home. It would be a shame to see attacks be a cause for change, so it may be better to call this out as an area of concern (consideration for security). I'd hate to have someone able to play with my heat while I am away at an IETF meeting and come home to frozen pipes because I had a discuss on their draft ;-) How about adding the last sentence to Alissa's proposed text: "In certain situations, energy and power monitoring can reveal sensitive information about individuals' activities and habits. Implementors of this specification should use appropriate privacy protections as discussed in Section 9 of RFC 6988 and monitoring of individuals and homes should only occur with proper authorization. Secure authenticated access via SNMPv3 implemented in such devices is RECOMMENDED to prevent unauthorized write access that could be used to attack individuals and devices in their homes." I'll note that Tero called this out in his SecDir review too. Thanks for updating to the new boilerplate as a result. I do think some mention of the security implications are important, otherwise, we won't get the level of security needed to protect IoT devices in the home.
I support the issues raised by Alissa and Kathleen.
Section 11 is missing a discussion of the privacy considerations of energy and power monitoring. I would suggest something along the lines of the following: "In certain situations, energy and power monitoring can reveal sensitive information about individuals' activities and habits. Implementors of this specification should use appropriate privacy protections as discussed in Section 9 of RFC 6988 and monitoring of individuals and homes should only occur with proper authorization."
Section 12.1: "New Assignments (and potential deprecation) to Power State Sets shall be administered by IANA and the guidelines and procedures are specified in [EMAN-FMWK], and will, as a consequence, the IANAPowerStateSet Textual Convention should be updated." Not sure what this sentence means.
former discuss, we processed this. -12 should soon be forthcoming to address the accidental inclusion of eoPowerStorageType StorageType in draft 11 which was merged from a previous draft.
draft-ietf-eman-energy-aware-mib
Please see. [1] [1] https://datatracker.ietf.org/doc/draft-ietf-eman-energy-monitoring-mib/ballot/#stephen-farrell
Overall, I think this is a good draft and appreciate the work that has gone into the security considerations template. I'd like to discuss options to address some concerns that came up for a few IoT related MIBs this week and see if we can address this more holistically. The concerns popped up in SecDir reviews, my review, and Alissa called out some privacy related concerns that face individuals and homes (security folks are worried about attacks to individuals and homes). #1. Is it time to update the MIB security considerations template to include privacy considerations and a mention of the importance of the protections for all environments including home and those that effect an individual? I think it would save us a lot of time and would be helpful. I think the security considerations are very good, but that adding a statement that the recommendations for secure authenticated access controls applies to home networks would be good. This additional text would also explain privacy considerations that Alissa proposed (in another discuss for draft-ietf-eman-energy-monitoring-mib-12). I'd hate to see assumptions that a home device doesn't matter when developers/implementer reads the security considerations section for MIB drafts related to IoT. Would it work better if this was a subsection that gets added only for IoT related MIBs? Here is the text again, with a sentence added for security: "In certain situations, energy and power monitoring can reveal sensitive information about individuals' activities and habits. Implementors of this specification should use appropriate privacy protections as discussed in Section 9 of RFC 6988 and monitoring of individuals and homes should only occur with proper authorization. Secure authenticated access via SNMPv3 implemented in such devices is RECOMMENDED to prevent unauthorized write access that could be used to attack individuals and devices in their homes." For the energy aware mib, a few settings popped out as having potential for damage. I am not asking that they get addressed directly, something along the lines of the above text would be good enough for me. The draft already calls out the read/write objects, which is great, so there is no need to call out specific attacks that could occur using these settings to an individual or home (IMO). When I went through the draft, I did try to think through possibilities for attacks, but will leave that out as to keep the discussion focused and see how we might improve the considerations. #2. In the first paragraph of the Security considerations template, a change to the sentence on implications of SET operations would also be helpful. It seems that all of the SecDir reviewers (& I) had fun thinking up scenarios that are becoming real that we would rather see avoided for the IoT related reviews. The following sentence in the current template doesn't cover the attack implications that are possible for IoT if some of the possible SET operations are attacked: "The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations." We are moving to a world where the security of the environment can be effected, where a home or individual can be attacked in new ways (burst pipes in the winter through heating settings, muck with backup power to the refrigerator spoiling food during a power outage, set alarms on batteries to go off as an annoyance or to not go off at all to do real damage to home, building, etc.). Tero and Steve K. came up with a few 'fun' attacks as well. How about changing the above sentence to the following (or to something that gets at the same point): "The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations or leave cyber physical devices used by individuals, homes, and business vulnerable to attack." Steve Kent's SecDir review: http://www.ietf.org/mail-archive/web/secdir/current/msg04897.html For the energy monitoring mib review: http://www.ietf.org/mail-archive/web/secdir/current/msg04881.html Thanks!
Nit on Page 15, start of last sentence in the following section, should be "If" instead of "f", I think. eoEthPortIndex OBJECT-TYPE SYNTAX PethPsePortIndexOrZero MAX-ACCESS read-only STATUS current DESCRIPTION "This variable uniquely identifies the power Ethernet port to which a Power over Enternet device is connected . If the Power over Ethernet MIB RFC 3621 is supported by the SNMP agent managing the Energy Object, then the Energy Object eoethPortIndex MUST contain the corresponding value of pethPsePortIndex. f such a power Ethernet port cannot be specified or is not known then the object is zero." REFERENCE "RFC 3621 " DEFVAL { 0 }
I do support Kathleen's concerns about updating the security considerations for IoT MIBs.
Holding this pending the resolution of the discussion about the security considerations boilerplate that started with the other energy monitoring MIBs.
draft-ietf-eman-battery-mib
I've been concerned since the requirements document came out, and mentioned it again when the framework document came out, that this WG has not taken seriously energy management that is beyond the realm of very small devices with very small power consumption and a limited kind of battery bank. This MIB is a clear indication to me that the WG still has not taken larger more complicated systems into account. I am not an expert on these systems; I know a limited amount from the work I do with renewable energy systems. But there are obvious omissions from this MIB that make me believe that the WG did little research into the needs of systems that I am sure would be using this kind of MIB. I have below some additions that I think are obviously missing, but I think it is worth some research to find out if there are other features missing. (If MIBs are sufficiently extensible in current management systems that the following can be added later without causing disruption, then I'm happy to clear my DISCUSS if these things can be added later with ease. But I fear things may get locked-in in ways that will make it difficult to add in the future.) 3.1: Some battery characteristics that seem obviously missing from the list: - Recharge voltage: The low voltage at which the battery should be recharged, independent of raising an alarm - Equalization voltage: The voltage to be held for the equalization portion of the charging cycle - Bulk voltage: The voltage to rise to during the bulk stage of the charging cycle before transitioning to absorption - Absorb voltage: The voltage to be held for the absorption stage of the charging cycle - Float voltage: The voltage to be held by the charger after charging is complete - Absorb time: The time to spend in the absorption portion of the charging cycle - Temperature compensation: The value by which to change the charging voltage per degree based on the battery temperature These are features of batteries that a charger must know about in order to properly charge them, and they are characteristics that are specified by the battery manufacturer. These are all read-only. Some of them *might* be a range of acceptable values, so there might need to be some accommodation for that too. Also, adding a notification for *high* battery voltage seems important. 3.2: Why are the three types of lead-acid batteries -- Flooded, Gel, and Absorbed Glass Mat (AGM) -- not separated out as different types? Those types of batteries have very different charging characteristics, which a charging system is going to want to retrieve so that it can properly handle the battery, and they should have separate entries. The following are concerns I have with items in the current MIB: 4: What is the difference between batteryActualCharge and batteryActualCapacity? When could these values be different? (Similarly with the alarms that distinguish between the two.) The charging states (unknown(1), charging(2), fastCharging(3), maintainingCharge(4), noCharging(5), discharging(6)) and associated other data relating to charging states seems a bit odd. They appear more to be states of the charger than states of the battery. Many batteries don't "know" whether they are being charged vs. fast-charged vs. maintenance charged. If we are going to start introducing charger states into what the battery MIB, I think charge states like "absorbing charge", "bulk charge", and "equalizing charge" might also make sense. But this seems like a weird road to go down.
4: The description of batteryType says: "This object indicates the type of battery. It distinguishes between primary (not rechargeable) batteries, rechargeable (secondary) batteries and capacitors which are not really batteries but often used in the same way as a battery. The missing serial comma here is important, and you also need to put a comma before "which", or enclose that phrase in parentheses: NEW "This object indicates the type of battery. It distinguishes between primary (not rechargeable) batteries, rechargeable (secondary) batteries, and capacitors (which are not really batteries but often used in the same way as a battery). Rechargeable batteries *are* really batteries (which the original sentence denies), and all capacitors are "not really batteries", not just the ones that are used in the same way as a battery.
- Please see. [1] [1] https://datatracker.ietf.org/doc/draft-ietf-eman-energy-monitoring-mib/ballot/#stephen-farrell - I support Pete's discuss. And echo his concern that similar comments raised before on the reqs and framework don't seem to have resulted in the wg considering these issues. - I did not have time to fully read this sorry but I've also in the past asked if there are no issues with solar powered devices. I again see no mention of solar power nor of charge controllers (is that the same as a batter controller?) so I again agree with Pete that the coverage here doesn't seem correct - Pete's more concerned with BIG devices whereas I'm more concerned with those that might be deployed in odd and out of the way places:-)
1. There is a discrepancy between section 3.2 "Battery Technologies" and the related section 6.2 (IANA considerations) Section 3.2 mentions: New entries should be added to the IANA registry only if the respective technologies are in commercial use and relevant to standardized battery monitoring over the Internet. Section 6.2 mentions: Experts must check for sufficient relevance of a battery technology to be added. If the sentence in 3.2 is the guideline for the Expert Review, it should be mentioned in section 6.2. Alternatively a pointer to it should be provided. Here is a proposal. OLD: 3.2. Battery Technologies Static information in the batteryTable includes battery type and technology. The battery type distinguishes primary (not rechargeable) batteries from rechargeable (secondary) batteries and capacitors. The battery technology describes the actual technology of a battery, which typically is a chemical technology. Since battery technologies are subject of intensive research and widely used technologies are often replaced by successor technologies within an few years, the list of battery technologies was not chosen as a fixed list. Instead, IANA has created a registry for battery technologies at http://www.iana.org/assignments/eman where numbers are assigned to battery technologies (TBD). The table below shows battery technologies known today that are in commercial use with the numbers assigned to them by IANA. New entries can be added to the IANA registry if new technologies are developed or if missing technologies are identified. Note that there exists a huge number of battery types that are not listed in the IANA registry. Many of them are experimental or cannot be used in an economically useful way. New entries should be added to the IANA registry only if the respective technologies are in commercial use and relevant to standardized battery monitoring over the Internet. +----------------------------+----------+ | battery technology | assigned | | | number | +----------------------------+----------+ | Unknown | 1 | | Other | 2 | | Zinc-carbon | 3 | | Zinc chloride | 4 | | Nickel oxyhydroxide | 5 | | Lithium-copper oxide | 6 | | Lithium-iron disulfide | 7 | | Lithium-manganese dioxide | 8 | | Zinc-air | 9 | | Silver oxide | 10 | | Alkaline | 11 | | Lead acid | 12 | | Nickel-cadmium | 13 | | Nickel-metal hydride | 14 | | Nickel-zinc | 15 | | Lithium-ion | 16 | | Lithium polymer | 17 | | Double layer capacitor | 18 | +----------------------------+----------+ NEW: 3.2. Battery Technologies Static information in the batteryTable includes battery type and technology. The battery type distinguishes primary (not rechargeable) batteries from rechargeable (secondary) batteries and capacitors. The battery technology describes the actual technology of a battery, which typically is a chemical technology. Since battery technologies are subject of intensive research and widely used technologies are often replaced by successor technologies within an few years, the list of battery technologies was not chosen as a fixed list. Instead, IANA has created a registry for battery technologies at http://www.iana.org/assignments/eman where numbers are assigned to battery technologies (TBD). The table below shows battery technologies known today that are in commercial use with the numbers assigned to them by IANA. +----------------------------+----------+ | battery technology | assigned | | | number | +----------------------------+----------+ | Unknown | 1 | | Other | 2 | | Zinc-carbon | 3 | | Zinc chloride | 4 | | Nickel oxyhydroxide | 5 | | Lithium-copper oxide | 6 | | Lithium-iron disulfide | 7 | | Lithium-manganese dioxide | 8 | | Zinc-air | 9 | | Silver oxide | 10 | | Alkaline | 11 | | Lead acid | 12 | | Nickel-cadmium | 13 | | Nickel-metal hydride | 14 | | Nickel-zinc | 15 | | Lithium-ion | 16 | | Lithium polymer | 17 | | Double layer capacitor | 18 | +----------------------------+----------+ 3.2.1 Guidelines for Addition to the Battery Technology List New entries can be added to the IANA registry if new technologies are developed or if missing technologies are identified. Note that there exists a huge number of battery types that are not listed in the IANA registry. Many of them are experimental or cannot be used in an economically useful way. New entries should be added to the IANA registry only if the respective technologies are in commercial use and relevant to standardized battery monitoring over the Internet. OLD (section 6.2) New assignments of numbers for battery technologies will be administered by IANA through Expert Review ([RFC5226]). Experts must check for sufficient relevance of a battery technology to be added. NEW: New assignments of numbers for battery technologies will be administered by IANA through Expert Review ([RFC5226]). Experts must check for sufficient relevance of a battery technology to be added, according to the guidelines in section 3.2.1 2. While searching through the archives, I found that "Comments on draft-ietf-eman-battery-mib-12" from Alan Luchuk, March 12th 2014, (see http://www.ietf.org/mail-archive/web/eman/current/msg02255.html) has not been addressed. Note: version 12 is the version presented to the IESG Alan has got some valid feedback. 3. Batteries are indexed by the entPhysicalIndex of the entPhysicalTable defined in the ENTITY-MIB module [RFC6933]. An implementation of the ENTITY-MIB module complying with the entity4CRCompliance MODULE- COMPLIANCE statement is required for compliant implementations of the BATTERY-MIB module. If batteries are replaced, and the replacing battery uses the same physical connector as the replaced battery, then the replacing battery SHOULD be indexed with the same value of object entPhysicalIndex as the replaced battery. Can you please explain why a SHOULD and not a MUST? 4. There are 3 EMAN MIB modules on the IESG this week. On two of them, there is a discussion on changing the "Security Guidelines for IETF MIB modules". If this is changed, this should be changed for the 3 EMAN MIB modules. This DISCUSS is for document only.
- Copyright date in the MIB is pretty old :-) Copyright (c) 2010 IETF Trust and the persons identified as authors of the code. All rights reserved.
I'd like to see if an update to the security considerations for MIBs could be made. There are 3 different drafts that have IoT related security & privacy concerns that are not covered by the current template well enough. Concerns were raised in each of the SecDir reviews as well as in my own. I proposed some edits to the energy-aware mib that would also apply to this draft. See: https://datatracker.ietf.org/doc/draft-ietf-eman-energy-aware-mib/ballot/
Does battery storage for energy generated by solar/wind fit into this mib? I see that UPS is called out separately, but am wondering if battery storage has something separate or would have to fit here for now? I'm asking as the implications change in terms of security, privacy and the possible effects. The control would be the same (authenticated and secure SNMPv3 access), but considerations would change. The security considerations called out are specific to data loss, but if power to homes or buildings from solar/wind batteries is part of this, then the implications go far beyond data. In the home, if someone were interested in doing damage, they could easily change the settings that result in an alarm to prevent alarms from going off or to make them go off more as an annoyance. I'm not asking for that to be called out specifically.
Section 5 says: "All potentially sensible or vulnerable objects of this MIB module are in the batteryTable. In general, there are no serious operational vulnerabilities foreseen in case of an unauthorized read access to this table. However, privacy issues need to be considered. It may be a trade secret of the operator o how many batteries are installed in a managed node (batteryIndex) o how old these batteries are (batteryActualCapacity and batteryChargingCycleCount) o when the next replacement cycle for batteries can be expected (batteryAlarmLowCapacity and batteryAlarmHighCycleCount) o what battery type and make are used with which firmware version (batteryIdentifier, batteryFirmwareVersion, batteryType, and batteryTechnology)" The above is a list of corporate confidentiality issues, so I would suggest s/privacy/corporate confidentiality/. Furthermore, discussion of actual privacy issues -- affecting individuals -- is missing. Just as the document notes the corporate confidentiality issues, it should note the potential privacy issues, e.g., by adding something along the following lines: "For any battery-powered device whose use can be correlated to an individual or a small group of individuals, the following objects have the potential to reveal information about those individuals' activities or habits (e.g., if they are near a power outlet, if they've been using their devices heavily, etc.): batteryChargingCycleCount batteryLastChargingCycleTime batteryChargingOperState batteryActualCharge batteryActualVoltage batteryActualCurrent batteryTemperature batteryAlarmLowCharge batteryAlarmLowVoltage batteryAlarmLowCapacity batteryAlarmHighCycleCount batteryAlarmHighTemperature batteryAlarmLowTemperature Implementors of this specification should use appropriate privacy protections as discussed in Section 9 of RFC 6988. Battery monitoring of devices used by individuals should only occur with proper authorization."
draft-ietf-sidr-cps
My brain stumbled on the following text in 1.3: Describe how the registration authority function is handled for the CA(s) that you operate. The RPKI does not require establishment or use of a separate registration authority (RA) in conjunction with the CA function. What is the second sentence intended to address? I read it as meaning something like "The RPKI allows the RA to be operated either in conjunction with the CA function, or through a separate registration entity." But the subsequent sentences suggest that this is incorrect. So if it means the opposite of what I read, it should be stated directly so that it's clear what it means. E.g., "The RPKI does not allow for the establishment or use of a separate RA in conjunction with the CA function." In 3.1.5: Although it is desirable that these subject names be unique throughout the PKI, to facilitate certificate path discovery, such uniqueness is neither mandated nor enforced through technical means. I think you mean the two clauses at the end of the sentence to be distinct, but they read as expressing a single meaning. It might be clearer to say it this way: Although it is desirable that these subject names be unique throughout the PKI, to facilitate certificate path discovery, such uniqueness is not required, nor is it enforced through technical means. In 4.4.1: Any subscriber in good standing who holds INRs distributed by <Name What does "in good standing" mean? If this phrasehas a specific meaning, a reference would be helpful. If it doesn't, it has so many possible meanings that I think it might be better to use a more specific phrase. Or if it is simply whatever the policy of <Name of Organization> is for "in good standing," it would be good to make that explicit, since at least my tendency is to take it as having a common global meaning. In 8: List here any audit and other assessments used to ensure the security of the administration of INRs. These are sufficient for the RPKI systems. Does the second sentence mean that what is stated in the first sentence is all that is required, or that what is stated must be sufficient for RPKI systems? I can't come up with a clear meaning for this sentence. Despite my carping, this is a great document, and I'm glad to see it go by. Thanks for doing it!
I hope that someone more skilled in the art than I can explain how we handle copyright issues under TLP 4 Section 3.c.ii. Maybe Section 3.e covers us. Maybe the Trust can give us a paragraph to include in this document. I very much hope that this issue does not get in the way of progressing this work.
- 1.4.2: Why do we need this? I see the same is in 6484 (and would have commented simlarly on that had I been on the IESG then). I do not see any need for that at all but I expect that even if I'm right you probably want it so as to be consistent with 6484.
Having written an extensive CP and CPS for an organization, this template looks very good and appears to meet the expectations of users for a template such as this. Thank you for your effort on this draft.
I think I got a bout of denseness (density?) when I read this. It is an odd document, what with a preface that tells people to do a bunch of surgery to the document and then publish their own sorta-version of it and all. Many thanks to the document shepherd, Chris Morrow, for explaining the bits that I found odd or confusing. I wondered why it's a BCP. That was easy to explain. I wondered where these things would be published, if not RFCs, and I wondered why the huge amount of invariant text isn't just referenced, rather than being included in every CPS. In the end, I think a small bit of explanation in the preface would have done a lot for me, so let me suggest this, as a non-blocking comment. No need to respond to this, and do what you think best: OLD This document contains a template to be used for creating a Certification Practice Statement (CPS) for an Organization that is part of the Resource Public Key Infrastructure (RPKI). (Throughout this document the term "organization" is used broadly, e.g., the entity in question might be a business unit of a larger organization.) The user of this document should: 1. substitute a title page for page 1 saying, e.g., "<Name of Organization> Certification Practice Statement for the Resource Public Key Infrastructure (RPKI)" with date, author, etc. There is no expectation that a CPS will be published as an RFC. NEW This document contains a template to be used for creating a Certification Practice Statement (CPS) for an Organization that is part of the Resource Public Key Infrastructure (RPKI). (Throughout this document the term "organization" is used broadly, e.g., the entity in question might be a business unit of a larger organization.) There is no expectation that a CPS will be published as an RFC. Instead, the CPS will be published in ways similar to how such things as privacy policies and terms of service are published: as pages on the organization's web site and the like. Organizations are expected to use this template as a best current practice, rather than creating their own from scratch -- this document contains both invariant text that will appear in all Certification Practice Statements and places to fill in text that's specific to the CPS being created. The user of this document should: 1. substitute a title page for page 1 saying, e.g., "<Name of Organization> Certification Practice Statement for the Resource Public Key Infrastructure (RPKI)" with date, author, etc. END Of course, if you choose to accept this suggestion you should tweak the text of that paragraph appropriately: I'm sure I didn't get everything exactly right.
Preface: When someone uses this document to produce a CPS, what will the normative language mean once the reference to RFC 2119 is omitted? E.g., this text in Section 2.1 is not in angle brackets, so I assume it will be reproduced in every CPS: "As per the CP, certificates, CRLs and RPKI-signed objects MUST be made available for downloading by all relying parties, to enable them to validate this data." What is this kind of requirement supposed to mean when published in a CPS? (Similar question for 3.1.3). s/employed in the RFC/employed in that RFC/ Section 1.6: "An RPKI signed object is a digitally signed data object (other than a certificate or CRL) declared to be such by a standards track RFC" I find the "such" here ambiguous. Something is declared to be an object by a standards track RFC? Or declared to be a digitally signed object? Or declared to be an RPKI-signed object?
draft-ietf-xmpp-websocket
In the security considerations section, it would help to discuss how the security model possible using websockets compares to the security model available for regular XMPP. I find the lack of any discussion of this frustrating, but don't know enough about websockets to be able to describe the incongruity that seems to exist here. The action item for this DISCUSS would be either to add some text discussing this. I realize that that's vague, and so this is subject to negotiation on the call or by email—it's not my goal to hold up the document on this, just to see if it's possible to get more clarity. The thing that leads me to worry about this is the inability of the client to actually know who it is talking to; the current text that talks about web host metadata (second paragraph) is useful, but leaves me wanting a bit more detailed discussion. Aside from this and the comments below, the document is very clear and easy to follow. Thanks for doing it!
I agree with Pete's comment. In section 3.4, the example response does not include a "to" attribute as required by RFC 6120 section 4.7.2. Am I missing something? In section 3.5, are we sure that there are no connection initiation requests that could result in an error that would make it impossible to send a second frame? Also, what does the client do if it receives a badly-formed open response, or if it receives something other than an open in response to an open? In section 3.7, no reason is given for a stream restart being mandated. Can you add a reference here (I assume this is described in detail in RFC 6120)? In 3.8, suggest the following rewording: OLD: The use of either of these extensions (or both) MAY be used to determine the state of the connection. NEW: Either of these extensions (or both) MAY be used to determine the state of the connection. Similarly in section 4: OLD: Use of web-host metadata MAY be used to establish trust between the XMPP server domain and the WebSocket endpoint, particularly in multi- tenant situations where the same WebSocket endpoint is serving multiple XMPP domains. NEW: Web-host metadata MAY be used to establish trust between the XMPP server domain and the WebSocket endpoint, particularly in multi- tenant situations where the same WebSocket endpoint is serving multiple XMPP domains.
(1) section 6, 2nd para: that last "MAY be used" seems broken or am I wrong? You're saying that the webserver/websocket listener on ws.example MAY be delegated as trusted for use of this spec from the not-ws.example xmpp domain. I don't see how that works without allowing for trivial impersonation. Can you explain? (Sorry, didn't have time to go through the refs properly.) (2) Just checking: 6.1 calls for e2e xmpp security. Did someone check that this and that play nice together? Where that is either [1] or OTR. [1] https://tools.ietf.org/html/draft-miller-xmpp-e2e
- 3.1 you should explain the |thing| notation (or reference an explanation) - 3.6.1 - does the see-other-uri interact with the SOP if running say a JS client in a browser? How? (Is such an implementation a target?) - 3.8 - looks to me that this makes those two XEPs normative references. Just saying MAY does not mean that you don't have to read them to implement, you do. I hope that's not a problem for you but don't see that it should be since those are stable enough references I guess. - 3.9 - you say a "server" MUST NOT advertise TLS - that seems a bit wrong - perhaps that'd be better as "a websocket server's listener MUST NOT..." since I could have another listener in the same process even that does native xmpp/tls/tcp as well, right?
Dan Romascanu raised two issues in his Gen-ART review. I have not seen a response yet, but these points should be at least considered before approving the document.
Just a comment, not a showstopper by any means: Some of the MUSTs in this document seem kind of goofy. When I go to use a MUST, I usually ask myself, "What else could an implementer possibly do?", and if the answer is "If they don't do it, they're not implementing this protocol", then there's no need for the MUST. For example: 3.1: During the WebSocket handshake, the client MUST include the value |xmpp| in the list of protocols for the |Sec-WebSocket- Protocol| header. The reply from the server MUST also contain |xmpp| in its own |Sec-WebSocket-Protocol| header in order for an XMPP sub- protocol connection to be established. What else would an implementer do? Instead, try: In order to establish an XMPP sub-protocol connection, during the WebScoket handshake, the client includes the value |xmpp| in the list of protocols for the |Sec-WebSocket-Protocol| header, and the server includes |xmpp| in its own |Sec-WebSocket-Protocol| header in the reply. There are other examples of these sorts of uses in the document. On the flip side, it is useful to give requirements on the receiving side, like "An implementation MUST reject with an error any frame that does not begin with a '<'". An implementation might not think to do that, and it's important. The world doesn't end if you don't fix these up; that's why this is only a comment. Implementers will probably figure out that if the spec says, "Foobar MUST be X", they should probably reject foobars that aren't X. But I do think it would help implementers if you used MUSTs where an implementer might get themselves in trouble, not to define some sort of "conformance criteria". I think it's worth having a run through the document and convince yourselves where these are and aren't helpful uses of the term.
As noted by Jürgen in his OPS-DIR review: This document defines how to run XMPP over WebSockets. The intended status is standards track. I believe the document is in a good shape and basically ready to go. In particular, I do not see that the XMPP over WebSockets specification creates any operational issues. Some editorial nits: - Sec 1: The term 'raw socket' can be potentially mis-understood, perhaps simply remove 'over row sockets' completely (I think the message of the sentence remains intact without these words). - Sec 3.1: The text says that both client and server MUST have |xmpp| in the list of protocols for the |Sec-WebSocket-Protocol| header. The text does not detail what happens if this is not the case. Is there be a defined behavior if this protocol negotiation fails? - Sec 3.6.1: There is a closing parenthesis missing at the end of the first paragraph. - Sec 3.9: Word missing in "it MUST be enabled the WebSocket layer", perhaps you meant "it MUST be enabled _by_ the WebSocket layer"?
Thanks for addressing the SecDir comments: http://www.ietf.org/mail-archive/web/secdir/current/msg04891.html Found a nit: Section 3.9: There is a word or two missing in the following sentence: Instead, when TLS is used, it MUST be enabled the WebSocket layer using secure WebSocket connections via the |wss| URI scheme. (See Section 10.6 of [RFC6455].)
It would be useful to add a sentence at the end of the introduction that tells people where to find the XSF XEP documents, perhaps including a root URI. -- Section 3.1 -- The mechanism of using vertical bars instead of quotation marks jarred me at first, and I expected to see "|xmpp|" in the protocol. It didn't take long to figure it out, but, as the notation is different to what we usually write, it might be useful to note it in Section 2, and explain when you use vertical bars and when you use quotes (I think the difference is protocol elements vs. prose). It also might be useful to have a sentence introducing the example, which says, "The following is an example of a WebSocket handshake followed by an initial XMPP protocol exchange," or some such. (Or you might make the example a figure, and put that in as a figure caption.) -- Section 3.3.3 -- Editorial: The inclusion of XML declarations, however, is NOT RECOMMENDED as WebSocket messages are already mandated to be UTF-8 encoded and therefore would only add a constant size overhead to each message. The subject of "would only add" is dangling. I suggest this fix: NEW The inclusion of XML declarations, however, is NOT RECOMMENDED, as WebSocket messages are already mandated to be UTF-8 encoded. Inclusion of declarations would only add a constant size overhead to each message. END -- Section 3.6.1 -- Two nits: 1. "e.g." needs a comma after it (two places). 2. The first paragraph needs a second closing parenthesis before the final period. A non-nit: If the server wishes at any point to instruct the client to move to a different WebSocket endpoint (e.g. for load balancing purposes), the server MAY send a <close/> element and set the "see-other-uri" attribute to the URI of the new connection endpoint With respect to the "MAY": what are the other ways of accomplishing this? I think there aren't any; I think the "MAY" applies to the fact that the server can instruct the client, rather than (as written) how it does it. But you already start the whole thing with "If the server wishes," so I suggest that you just change "MAY send" to "sends" (and change "set" to "sets"). (I also think the second "MAY" isn't necessary, but at least it isn't wrong.) -- Section 3.8 -- Nit: I think you don't need a comma after "sub-protocol" (but you do need commas both before and after "as such"). In the second paragraph, "the use may be used" needs rewording. Just delete "The use of" to fix that. -- Sction 3.10 -- The passive voice here leaves a question open: Can either the client or the server initiate this? Or does it have be done by the client? It would be good to put it in active voice, I think, as "In order to alleviate the problems of temporary disconnections, the client MAY use the XMPP Stream Management extension...." And similarly for the second paragraph. -- Section 6 -- Nit: The last paragraph is missing a closing parenthesis after "[RFC6455]".
draft-ietf-hip-rfc5201-bis
This has outstanding IANA questions that need to be addressed, please.
I agree with Stephen's DISCUSS. The cryptographic algorithm choices here seem incrementally better than RFC 5201, but not very forward-looking.
This review is based on the diff from 5201 [1] [1] 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.
4.4.1: Maximum Segment Lifetime (MSL): Maximum time that a TCP segment is expected to spend in the network. TCP segment? First mention of use of TCP in this document.
I need to add a DISCUSS to Ted's on IANA registry issues. 1. It seems to me that this document needs to change all the registration entries that cite 5201, making them point to this document instead. 2. This document doesn't create the registries that it says it creates, and it shouldn't say that it does. But this document changes the registration policies of some of the registries, so it needs to make those changes clear. Perhaps (1) and (2) are already in the plan, in response to IANA's questions. 3. The last paragraph describing the Parameter Type registry says that "all other values" (it would be better to list them: 1024 through 32767 and 49152 through 61439) are assigned through "Fist Come First Served, with Specification Required." I realize the policy specification is unchanged from 5201, but it's not a valid policy combination. What is it intended to mean? FCFS and Specification Required are contradictory policies. Perhaps what you want is FCFS, with a documentation reference recorded in the registry. You can then say a few words about what registrants should make sure the reference document contains, but realize that it will not be validated by anyone for completeness or sensibility. 4. 5201 specified that the experimentation range ended at 49141; this changes it to 49151. I just want to make sure that was intentional, and not a typo. Will you confirm that? 5. In the table at the end of Section 5.2, the reserved range that follows the experimental one seems to have a typo in it: it says "41952", and should say "49152". There's also a discrepancy between the "61440 - 64443" range and the following "62464 - 63487" range. I have no idea which one has the typo there. 6. The comment in (3) about FCFS also applies to the Notify Message Type registry. Also, in the ranges given, the value 16384 doesn't fall in any range.
-- Section 4.1.8 -- Therefore, the Responder SHOULD should select its HIT from the same HIT Suite as the Initiator's HIT "SHOULD should" typo.
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?
Looking forward to seeing the discuss resolutions.
draft-ietf-ipfix-text-adt
Should this be PS instead of Informational?
Just one thing I'd like to ask: does IPFIX have any way to represent the special value "I'm not saying" for each of these basic types? If not, then I think this ought define such values for each type. The logic for that, is also related to a missing security consideration - IPFIX data in this format will likely be more easily searchable and aggregatable and hence more sensitive than binary or other formats. The idea would be that anyone creating or schlepping around data in this form would then have a well known way to elide values when they decide that's the right thing to do, and without confusing the receiver/reader into thinking that some odd value was real. Its kind of like NaN, but for privacy, and not arithmetical, reasons. Resolving this might mean defining such "not telling" values elsewhere, or here. So I might well accept punting on tihs if you tell me it'll be done, but please do push back if you think I'm just wrong in the above and don't ask to punt on this if you disagree with it (yes, its been known to happen;-). I do think noting the new security consideration would be good regardless but that is not by itself discuss-worthy.
Is there any particular reason to insist that white space in octet arrays be inserted at octet boundaries? It seems like you could just have the ABNF be "octetarray = 1*(hex-octet [WSP])", and deal with odd-length arrays either by forbidding them in text or by zero-padding. It could be helpful to clarify that the min/max values in Table 1 and Table 2 are decimal. It seems odd to allow hex/binary for unsigned, but only decimal for signed. Couldn't you just say "signed = [sign] unsigned"? Nit: ".." at the end of Section 4.7.
-- Section 4.1 -- octetarray = 1*(hex-octet [WSP]) I'll note that this allows an octetarray to have trailing WSP. If that's intended, that's fine, but it does differ from what the text says. If you want to fix it, this will work: NEW octetarray = hex-octet *([WSP] hex-octet) END -- Section 4.3 -- Please fix the table entry for "signed64" so that the minimum value is all on one line. -- Section 4.4 -- In the ABNF for "naninf", it's not strictly required but it would help readability to put parentheses around << sign "inf" >>. -- Section 4.7 -- Last paragraph: nicely dodged. :-)
I'd just note that some of the considerations expressed in section 4.7 do seem like security considerations given the relative dangers associated with string processing.
draft-ietf-pce-questions
good document!
There was some good points brought up in the SecDir review, with helpful responses (thanks Adrian). I'd like to see improvements from the SecDir review, still in discussion: http://www.ietf.org/mail-archive/web/secdir/current/msg04910.html 1. On Ben's first point, could a reference be provided since this draft is discussing stuff that exists (security considerations are included in...) >> Indeed, this RFC discusses many things that have quite serious >> security considerations, without mentioning any of them. For example, >> section 4 "How Do I Find My PCE?" (the very first question) advocates >> a number of potentially completely insecure mechanisms with no mention >> of their security properties (or otherwise). This is obviously >> pervasive, given the stance taken in the security considerations. 2. For Ben's second question, Adrian provided a list of references, are they already planned to be included in the next update? From Adrian: > Previous PCE RFCs have given some attention to security concerns in the use of PCE (RFC 4655), PCE discovery (RFC 4674, RFC 5088. RFC 5089), and the PCEP (RFC 4657 and RFC 5440). As such, "PCE Security" was not deemed by the authors to be a previously "unanswered question" and so did not need attention in this document. From the rest of the discussion, I'd be happy to see the issues called out with references on where to find more information. This strikes a balance and ensures the security considerations are made known to the user and provides the pointer of where to look. I agree that we don't need to bloat the draft, but do agree that the issues should be made known. Thanks!
Nice draft, just found a nit and figured I'd point it out so it doesn't get forgotten. Nit: In the last sentence of #8, I think "provide" should be "provider". In fact, each service provide could run its own parent PCE while allowing its child PCEs to be contacted by outsider parent PCEs according to configured policy and security.
This ain't no thang, really... a small procedural point: --------------------------- [I-D.ietf-pce-stateful-pce] Crabbe, E., Medved, J., Minei, I., and R. Varga, "PCEP Extensions for Stateful PCE", draft-ietf-pce-stateful-pce, work in progress. Note as per [RFC4897] This reference is to a target document that is not yet published as an RFC. Readers should exercise caution since the referenced document might be less stable than this document, however the essential description of the stateful PCE is considered t be stable at this time. [Note to RFC Editor: Per RFC 4897, publication of this document does not need to be held pending the availability of this reference as an RFC. Please remove this note before publication.] --------------------------- Methinks you misunderestimate RFC 4897: it is talking about citing a published RFC that's at a lower level of maturity than the source document (see Section 5 of 4897). It does *not* cover normative references to Internet drafts, nor should it. This document will have to wait in the RFC Editor queue until the stateful-pce document is ready, and the above notes should be removed (along with the reference to 4897).
Just noting that in Sections 4 and 9, ALTO is not the only protocol to use the RFC 4848 mechanism for server discovery -- discovery of a local location information server (RFC 5986) was previously specified this way and was, I believe, the inspiration for the ALTO mechanism.
draft-ietf-sidr-bgpsec-reqs
The mixed use of 2119 language could do with being tidied up to remove any implication that there is meaning in the inconsistency. Actually, when I read 3.1-3.3 I was rather pleased at the use of lower case words (as a speaker of English :-) and then got grumpy in 3.4. I won't make a big thing of whether you choose to go upper case or lower case, but your mixed usage is a little bit awkward. Probably, given the wide scale usage in the rest of the document, you probably just want to fix up 3.1-3.3 and quickly check the rest of the document. 3.11 has "it need NOT handle" which needs "not".
I'm not sure if this would be a good or bad idea but I'll ask anyway since I'm happy to embarrass myself if it might help:-) Feel free to chat about or entirely ignore this. From time to time I get asked if there's any work to be done with BGP (or interdomain routing) that might help to make pervasive monitoring harder. I always answer "dunno, what do you think?" since I do not know. Would it be worth adding a requirement here that designs should consider whether and if so the extent to which confidentiality being a part of BGPsec might be beneficial? I guess there's no formal need to add this since we do have a BCP on the topic (BCP188) but it might be something that designers would not otherwise consider, so a mention could be useful.
I'm not sure what you mean by saying that origin validation doesn't provide "cryptographic assurance". Do you mean to say something like "authentication of the originator of the route"? If I'm understanding correctly, the issue you're trying to point out here is that a ROA lets a prefix holder say "AS $foo may originate prefix $bar", but it doesn't prove that "This announcement for prefix $bar was originated by AS $foo" Nit: "The authors wishe"
On top of what Adrian wrote, there is always the question of what a SHOULD mean in a requirements document. Here are some examples of recent requirements documents. 1. http://www.rfc-editor.org/rfc/rfc7262.txt RFC 2119 keywords, but only MUST. No SHOULD or MAY 2. http://www.rfc-editor.org/rfc/rfc7226.txt RFC 2119 keywords with MUST/SHOULD/MAY With an explanation of the meaning: Any statement that requires the solution to support some new functionality through use of [RFC2119] keywords should be interpreted as follows. The implementation either MUST or SHOULD support the new functionality, depending on the use of either MUST or SHOULD in the requirements statement. The implementation SHOULD, in most or all cases, allow any new functionality to be individually enabled or disabled through configuration. A service provider or other deployment MAY enable or disable any feature in their network, subject to implementation limitations on sets of features that can be disabled. 3. http://tools.ietf.org/html/draft-ietf-cdni-requirements-17 (RFC EDITOR QUEUE) o "High Priority": When a requirement is tagged as "{HIGH}", it is considered by the working group as an essential function for CDNI and necessary to a deployable solution. This requirement has to be met even if it causes a delay in the delivery by the working group of a deployable solution. o "Medium Priority": When a requirement is tagged as "{MED}", it is considered by the working group as an important function for CDNI. This requirement has to be met, unless it is established that attempting to meet this requirement would cause a delay in the delivery by the working group of a deployable solution. o "Low Priority": When a requirement is tagged as "{LOW}", it is considered by the working group as a useful function for CDNI. The working group will attempt to meet this requirement as long as it does not prevent meeting the "High Priority" and "Medium Priority" requirements and does not cause a delay in the delivery by the working group of a deployable solution. 4. https://datatracker.ietf.org/doc/rfc6988/ No RFC 2119 keywords. I'm not religious at all on which way you chose, but 1. be consistent (right now, it's not the case) 2. explain how the protocol spec. authors must interpret SHOULD/MAY/OPTIONAL (or should/may/optional) requirements. From the early discussion between Adrian/Randy, I understand there is a willingness to fix this. Therefore that's a COMMENT (I have nothing against the technical content). If you produce a new version ... == Outdated reference: draft-ietf-sidr-bgpsec-threats has been published as RFC 7132 == Outdated reference: A later version (-03) exists of draft-ga-idr-as-migration-01 == Outdated reference: A later version (-01) exists of draft-ietf-sidr-lta-use-cases-00
There is an interesting discussion going on in reference to Russ' draft on algorithm agility on the SAAG list, where folks are advocating for the pros and CONS to be included. Would an informational reference be possible in requirement 3.21? I don't know the timeline for this draft: https://datatracker.ietf.org/doc/draft-iab-crypto-alg-agility/ The SecDir reviewer had a few questions resulting from not being familiar with some of the terms used. I am in an environment where data and control plane discussions come up, so the text is fine for me, but I do see his point and think it would be wrath adding a little more detail to the following sentence in the Security Considerations section. I think you are talking about the path of each. Maybe change from: The data plane might not follow the control plane. To: The data plane might not follow the path of the control plane. SecDir review: http://www.ietf.org/mail-archive/web/secdir/current/msg04876.html
What Adrian said...
Would like to see the 2119 usage sorted out per the others' comments but otherwise looks good to me.
draft-ietf-stir-threats
Not sure what the following text adds to the document. Either there is too much or too little information. I have no idea what some of these attacks mean: Some of the attacks that should be considered in the future include the following: Attacks Against In-band Token replay Baiting a call to a chosen number with a REFER Removal of in-band signaling features Attacks Against Out-of-Band Provisioning Garbage CPRs Data Mining Attacks Against Either Approach Attack on directories/services that say whether you should expect authenticated calling number data or not Canonicalization attacks
The draft was an interesting read, thanks for your work on it to develop the threat models. I just have some questions from thinking about a few of the discussion point and not being familiar with the controls currently in place, so please bear with me (all non-blocking questions/comments): In Sect 3.2, The following seems odd to me, wouldn't the robocall program know to avoid numbers that raise suspicion and why aren't they just blocked outright as source numbers? A robocaller may impersonate a number that is not an assignable number (for example, in the United States, a number beginning with 0), Beyond checking that a number is valid, is there really much that can be done? If there is some sort of validation check against incoming numbers, helpful robocalling or texting could be blocked (local robocalls for storms, airlines notifying on changes, etc.). Source numbers can change, if you block based on an unknown source (maybe something you have not subscribed to receive), you may miss something important. If someone has not opted out (asked to not receive unsolicited calls), in the US at least, nothing prevents the caller from placing the call (legally). Is anything changing on that or are we bound to those restrictions? I'll also watch for a response to Benoit's comments. Thanks.
I'm a yes. Let's start with that. I agree with Benoit's point about the list of attacks with no details. In addition, the document title sounds like it's a complete analysis of STIR threats, but if I'm reading it correctly, there are a number of threats that aren't being considered (because the threats related to robocalling are considered to be the major concerns, did I get that right?). You might want to consider adjusting the document title a bit.
I agree with Benoit's comment about Section 4.1. The attacks listed should either be further elaborated or the list should be removed.