IESG Narrative Minutes
Narrative Minutes of the IESG Teleconference on 2016-10-13. 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
2.2 Individual submissions
2.2.1 New items
2.2.2 Returning items
2.3 Status changes
2.3.1 New items
2.3.2 Returning items
3. Document actions
3.1 WG submissions
3.1.1 New items
Telechat:
Telechat:
Telechat:
3.1.2 Returning items
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
Telechat:
3.4.2 Returning items
1054 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
Telechat::
Telechat::
Telechat::
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::
Telechat::
Telechat::
Telechat::
Telechat::
Telechat::
7. Working Group News
1130 EDT adjourned telechat, recording stopped, but conflict-resolution started; Scribe left
(at 2016-10-13 06:00:47 PDT)
draft-ietf-tsvwg-rfc5405bis
Hi, thanks for this document. I just have a few nit level comments: - I agree with Benoit that a more detailed "changes since 5405" section would be helpful (separate from the inter-version change section.) - IDNits points out that RFC 896 is obsoleted RFC 7805. Is the reference to 896 intentional? (The shepherd writeup mentions a different obsolete reference, but not this one.) - 3, 2nd paragraph: Is it reasonable to avoid the negation in "not rare" and just say "common"? -3.1.1, 3rd paragraph: Please expand TFRC on first mention. (I think the original 5405 text that expanded it got moved to later in the document.) -3.4, paragraph 3: "An application MAY optionally discard UDP datagrams with a zero checksum [RFC1122]" Does this MAY give permission to discard, or state the fact that 1122 gives permission to discard? (If the second, please consider non-2119 language to avoid the ambiguity.) -3.4.1, last bullet in list: I think there may be an editing or copy/paste error here. (Limit the usage of what? Is that section 3.6 _of_ RFC7510?) -3.6: Yay! - section 6, third paragraph: "Applications MAY also want to offer ways to limit the number of requests they respond to in a time interval, in order to cap the bandwidth they consume." Is that MAY intentionally capitalized? Seems like a statement of fact. -section 6, paragraph 5: I concur with Kathleen's comment to reference 7525 in the DTLS discussion.
Thanks for updating this. I have one real question to ask, and a few nitty things... Some of the text in section 6 seems outdated, e.g. I'm not sure we'd recommend GSS-API or AH these days. I wonder would that section be worth running by the saag list to see if anyone has time and interest to offer better text? (I would be happy to try write such text myself but other than the bit below, don't have time right now, sorry.) Note that my review is based on the diff from 5405 [1] - General: I wondered if the folks interested in QUIC have been involved with this? I assume they have and that this update won't cause issues with the just-formed QUIC WG. (If we did expect such issues, then we probably ought be explicit about that and I didn't see any mention of QUIC in this document.) - 3.1.1: "Latency samples MUST NOT be derived from ambiguous transactions" - I don't understand how that MUST NOT can be universally applied, maybe that's just a use of 2119 terms for emphasis? - 3.1.2: I wondered if there's anything useful to say about LPWAN applications that may meet the "don't send much" criterion, but I assume it's too early to say most likely. - (some text that moved, which I why I noticed it:-) section 6 says: "Applications that respond to short requests with potentially large responses are vulnerable to amplification attacks, and SHOULD authenticate the sender before responding. The source IP address of a request is not a useful authenticator, because it can easily be spoofed. Applications MAY also want to offer ways to limit the number of requests they respond to in a time interval, in order to cap the bandwidth they consume." I think that's a bit wrong and a bit out of date. I'd suggest instead maybe something more like: "Applications that respond to short requests with potentially large responses are a potential vector for amplification attacks, and SHOULD take steps to minimize their potential for being abused as part of a DoS attack. That could mean authenticating the sender before responding noting that the source IP address of a request is not a useful authenticator, because it can easily be spoofed. Or it may mean otherwise limiting the cases where short unauthenticated requests produce large responses. Applications MAY also want to offer ways to limit the number of requests they respond to in a time interval, in order to cap the bandwidth they consume." [1] https://tools.ietf.org/rfcdiff?url1=rfc5405&url2=draft-ietf-tsvwg-rfc5405bis-18.txt
Well written doc! Thanks! One comment, not really an issue, just want to mention it: Recommendations on "Limited Applicability and Controlled Environments" seem slightly redundant (in section 3.6 but also two times earlier in the doc). Maybe it would be helpful to at least have the definition of 'General Internet' and 'Controlled Enviroment' (currently in section 3.6) earlier in the doc...?
Before starting to read this document, a first reaction: let me stress that
this type of document should really benefit from a "changes since RFC5405"
section.
I see in the abstract:
This document obsoletes RFC5405 and adds guidelines for multicast UDP
usage.
I see in the intro section:
[RFC5405] was scoped to provide guidelines for unicast applications
only, whereas this document also provides guidelines for UDP flows
that use IP anycast, multicast, broadcast, and applications that use
UDP tunnels to support IP flows.
Looking at the diffs, there is certainly more than this
https://www.ietf.org/rfcdiff/rfcdiff.pyht
=> https://tools.ietf.org/rfc/rfc5405.txt
=> https://tools.ietf.org/id/draft-ietf-tsvwg-rfc5405bis-18.txt
Background:
https://datatracker.ietf.org/doc/draft-wilde-updating-rfcs/ and the related
discussion on having a "changes since RFCxxxx", even for obsolete.
Thank you for a very well-written draft! When DTLS is discussed in the security considerations section, could you include a pointer to the best practices: https://tools.ietf.org/html/rfc7525 Thank you for also for addressing the SecDir review: https://mailarchive.ietf.org/arch/msg/secdir/fOv00Tugy6CjPOuoReu2jHKS38k
= Section 3.17 =
"An application sending ECN-capable datagrams MUST provide an
appropriate congestion reaction when it receives feedback
indicating that congestion has been experienced. This must result
in reduction of the sending rate by the UDP congestion control
method (see Section 3.1) that is not less than the reaction of TCP
under equivalent conditions."
Is the second "must" meant to be normative? If so, this worries me a bit. RFC
6679 I believe retains flexibility for endpoints to react to congestion in ways
that are different from TCP and dependent on specific codecs, topologies, and
other factors. RFC 3551 provides a lot of qualification in the requirements it
places around equivalence to TCP's behavior. So I would be concerned about how
this requirement, if normative, would affect RTP and other protocols.
If it's not meant to be normative, I would suggest using "ought to" or some
other word.
Tim Chown performed the opsdir review
draft-ietf-ospf-two-part-metric
Two quick questions: 1) Why does this doc update 2328 and 5340? I would assume an TLV extension does not need to update the base protocol. 2) Why is the OSPFv3 extension described in a separate document?
abstract: the text doesn't really explain anything to me. But then I'm not familiar with OSPF so maybe it's obvious to someone who is. intro: expanding LSA, VPLS etc on 1st use would be better. 3.1, 2nd bullet: the text here was very unclear to me (All that said, the satellite/mobile ground station example does enough to ensure that the overall document is clear so the above are nitty nits:-)
Sorry for being dense, but:
3.2. Advertising Network-to-Router Metric in OSPFv2
For OSPFv2, the Network-to-Router metric is encoded in an OSPF
Extended Link TLV Sub-TLV [RFC7684], defined in this document as the
Network-to-Router Metric Sub-TLV. The type of the Sub-TLV is TBD2.
The length of the Sub-TLV is 4 (for the value part only). The value
part of the Sub-TLV is defined as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MT | 0 | MT metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
I don't believe the document explains what are valid values of the MT field.
Help?
If the update to RFC 5340 is kept, it should be mentioned in the abstract.
Victor Kuarsingh <victor@jvknet.com> performed the opsdir review
draft-ietf-netconf-restconf
(I would have balloted DISCUSS based on the major comment, but Alexey beat me to it:) Major: - 4.6: The first patch says the sever MUST support PATCH, and also that implementation of PATCH is optional. Language in 4.1 seems to assume the latter. Minor: - 2.5: I'm a bit surprised to see basic authentication encouraged to the same degree as other options. - 5.2: Did the working group consider the interoperability impact of not making either encoding MTI? - 12, paragraph 4: Please consider not repeating the 2119 language from other sections. Editorial/Nits: -1.4, 6th paragraph: "...then this commit will act as the confirming commit": Which commit is "this" commit? - 5.3, first sentence: Missing word?
- What about tls1.3 0RTT/replayable-data? There may be a case to be made to mention this here and e.g. to say that only idempotent requests (or none) are allowed use 0RTT early data. Equally you could argue to not say anything since tls1.3 isn't yet finished. I'd argue that saying something here is better (and that saying to not use 0RTT at all is best) since RESTCONF will use standard https libraries, which will at some point soon support 0RTT and that might even make that happen more easily than they ought. (This isn't a discuss as tls1.3 isn't yet done so I'd not feel right blocking on this basis, but were tls1.3 done, which it will be soon I hope, this would be a definite discuss as RESTCONF differs enough from a browser for this to be a cause of possibly really bad security problems.) 1.4: "Note that there are no interactions at all between the NETCONF protocol and RESTCONF protocol. It is possible that locks are in use on a RESTCONF server, even though RESTCONF cannot manipulate locks. In such a case, the RESTCONF protocol will not be granted write access to data resources within a datastore." What you mean is clear, but the text is, I think, self-contradictory - what is described is an interaction between the two protocols. (And so is the fact that access controls need to be commensurate between the two protocols.) - section 2: would it be useful to add a reference to BCP195 and say that adhering to that is a good idea? I think you could maybe actually lose some (but not all) of the text here via that single reference. (That might help a bit with Alexey's discuss, not sure.) - 2.5: "MUST use tls-cilent-auth or MUST use any HTTP authentication scheme" is (as Kathleen noted) wishy washy. And that leaves out html-form-based client auth methods too it seems. I think you could word this better. (Not that that's likely to affect the reality that clients here will just use web engines so there's probably no point in expecting that RESTCONF can use anything out of the ordinary.) The same comment applies to section 12 where the same wishy-washy statement occurs. - 12: "There are many patterns of attack..." that screams out for references, please add some to give the reader a chance to understand if they don't already know.
Thank you for a well written document. I have a few minor points which I would like to discuss before recommending approval of this document: 1) In 2.4: TLS server identity verification using RFC 6125 is underspecified. Please provide all details as described in Section 3 of RFC 6125, in particular, please specify which of CN-ID, DNS-ID, SRV-ID, URI-ID are allowed/required and whether wildcards are allowed in them. 2) In 3.5.3.1: api-path is using "|" instead of "/" for alternatives. The "*" must be before a rule, not after it. It looks like the ABNF was not validated with a tool, so there might be other errors in it. 3) In 4.6: ... server MUST support the PATCH method. ... . It is optional to implement by the server. - These statements seem to be in conflict. 4) In 5.2: The server is only required to implement one of XML / JSON. Does this mean that a compliant client need to support both in order to achieve interoperability? The document doesn't say that.
In 1.4: is it possible to expose separate :candidate, :startup and :writeable-running over RESTCONF? Section 1.4 seem to imply that only one can be used. In 3.5.3: you are listing "reserved" URI characters, you should point to RFC 3986 as the authoritative reference. In 4.4.2: can 404 be returned instead of 403? On page 45 (in the middle of the page): some references to RFCs and sections look incorrect (wrong formatting). In 4.5: it would be good to see an example creating/replacing the whole datastore. At the bottom of page 47: I see an extra dot in the middle of a sentence. In 4.8.4: I think XPath should be a normative reference there. In 5.5: what is the reason for Cache-Control being a SHOULD and not a MUST? In 11.3.1: Subtype must include "+xml" in its value. Fragment identifier: can you just say "same as for application/xml"? File extension: don't you want to define a new one? (.xml is fine as a fallback) 11.3.2: The same comment about file extensions as above.
The draft is nicely written, thank you for that. I have a point in the security consideration section that I think is important to clarify in the draft. Authentication for RESTconf - The method for HTTP authentication vary and some are really bad (HTTP Basic, digest isn't too far behind it). This draft just requires some method, but I think a warning to research the methods since they have widely varying security levels is important. For the HTTP Authentication methods, the RFCs cover the pitfalls well. Here is the sentence: Client authentication MUST be implemented using client certificates or MUST be implemented using an HTTP authentication scheme. How about: Client authentication MUST be implemented using client certificates or MUST be implemented using an HTTP authentication scheme. The strength of these methods vary greatly and (certificates are recommended or HTTP basic is not recommended). Digest isn't great either, but at least not recommending basic would be good. There are also a few newer experimental HTTPAuth methods that improve things, but are experimental. One gets rid of stored passwords (HOBA).
I'm not sure how PATCH is MUST support but optional to implement in The RESTCONF server MUST support the PATCH method. RESTCONF uses the HTTP PATCH method defined in [RFC5789] to provide an extensible framework for resource patching mechanisms. It is optional to implement by the server. Can you help me understand?
Thanks for your work on this. (1) I'm curious how the WG settled on using Server-Sent Events. My understanding is that the SSE framework is somewhat brittle when used on its own and there can be problems when there are intermediaries in the path. Did the WG consider other options (e.g., H2 server push or long polling)? (2) I know the jukebox module is just an example, but it actually made me wonder if there would ever be cause for the server to return a 451 status code in response to a POST or GET request rather than a 401 or 403. Obviously there is no analog in the netconf status codes and the use for this would be pretty atypical, but figured I would mention this thought since it occurred to me.
draft-ietf-regext-epp-rdap-status-mapping
A few minor comments: - I guess this doc should cite RFC5730 and RFC7482 (?) in the intro...? - I would propose to directly put the link to the registation in the introduction instead of using a citation ([rdap-json-values]) because I initially didn't realize that this not a doc. - And effectively you could even remove section 2 mostly or potentially even competely as all information are given (word-for-word) in the IANA consideration section. And thanks for the nice in in-depth shepherd write-up!
Maybe it's obvious to everyone else, but what is the goal of these mappings? It would help to have a paragraph or two explaining that. (Or did I miss something?) Are the mappings reversible? -1, last paragraph: The MUST probably doesn't need a 2119 keyword. IIUC, it's a requirement on this draft, not on implementations.
Agree with Mirja that other than the final mapping, section 2 seems mostly redundant with the IANA considerations section and could be removed.
Ersue, Mehmet (Nokia - DE/Munich) <mehmet.ersue@nokia.com> performed the opsdir review
draft-ietf-core-etch
I'm following most of your reasoning behind having the twin methods PATCH and iPATCH, but I'm struggling a bit that there's nothing that I saw that prevents a problem when the client implements only PATCH and the server implements only iPATCH. The only text I saw that provides guidance about which method to implement is A client can mark a request as idempotent by using the iPATCH method instead of the PATCH method. This is the only difference between the two. The indication of idempotence may enable the server to keep less state about the interaction; some constrained servers may only implement the iPATCH variant for this reason. Maybe I missed something? If not, I saw There is no guarantee that a resource can be modified with PATCH or iPATCH. so, maybe that mismatch isn't going to be a problem in practice, but it seems sad that you might have a patchable resource, that can't be patched because of that mismatch. I'm not asking for "clients MUST implement iPATCH if you implement PATCH" (which would accommodate servers that only implement iPATCH), but I wonder if the working group talked about a way to avoid this mismatch?
I was a bit uneasy with the "nearly" in The security considerations for PATCH or iPATCH are nearly identical to the security considerations for PUT ([RFC7252]). with no explanation of any differences, but I'll leave that for the SEC ADs to pick up on if it matters.
Does this doc update RFC7252? Maybe not; just asking...
I share the concerns from Alissa's DISCUSS point and comment about section 5.
I agree with the comment made by the ops-dir reviewer, and I don't think the parenthetical in 2.2.1 addresses the problem. It seems that FETCH is not a useful operation unless the server is capable of understanding what it is supposed to fetch. So it's not true that "any" media type can be used, but rather only those media types for which a definition exists for what the fetch parameters indicate and which part of the resource they are intended to delineate. Shouldn't the use of FETCH be constrained to such media types?
= Section 2 = "(However, while processing a search request, a server can be expected to allocate computing and memory resources or even create additional server resources through which the response to the search can be retrieved.)" s/search/fetch/ would be clearer I think = Section 3 = "If the Request-URI does not point to an existing resource, the server MAY create a new resource with that URI, depending on the patch document type (whether it can logically modify a null resource) and permissions, etc." I know this is the same text as in RFC 5789, but it's vague. What else might create the basis for the server's decision besides the document type and permissions? = Section 5 = It seems that FETCH does introduce a new security consideration, in that any observer of FETCH requests can potentially glean information about the specific portions of a resource of interest to the requester. This might factor into decisions about whether to use DTLS to secure a particular request so may be worth mentioning.
[reflections on core, as opposed to actionable items for the document]
Coming back to Alissa's DISCUSS and Sheng Jiang's OPS DIR review:
This Standards Track document defines a new CoAP methods, FETCH, to perform
the equivalent of a GET with a request body; and the twin methods PATCH and
iPATCH, to modify parts of a CoAP resource. This document is well written.
I don't see any major issues from the operations and management
perspective. It is almost ready to be published. There are one of potential
major (the word potential means I don’t really sure how serious it may be)
comments from me:
In section 2.5, it raises an issue that “a FETCH request cannot be
generated from a link alone, but also needs a way to generate the request
payload.” From the discussion text, I am not sure whether there are
existing way to generate the request payload or not. And I am not sure
whether the FECTCH method needs a standard such way to be able to work or
not. If the answer for my first question is no, or the question for my
second question is yes. Then we probably have an major issue here. I wish
my suspecting is wrong.
I would like to make sure I understand (with my OPS background,):
- COAP (RFC7252) is about HTTP GET, POST, PUT, DELETE for constrained nodes and
constrained environments - draft-ietf-core-etch specification specifies the new
CoAP methods, FETCH, PATCH and iPATCH, which are used to access and update
parts of a resource. - CBOR (RFC7049) is the binary encoding of JSON for COAP.
And for draft-ietf-core-etch, I guess? - There are two data modeling language
in CORE
YANG: draft-ietf-core-yang-cbor-02 provides the mapping for YANG data models
encoding: CBOR
SenML: draft-ietf-core-senml-02 provides Media Types for Sensor Markup
Language
encodings: JSON, CBOR, XML, EXI
Good so far?
Coming to Alissa's DISCUSS:
It seems that FETCH is not a useful operation unless the server is capable
of understanding what it is supposed to fetch. So it's not true that "any"
media type can be used, but rather only those media types for which a
definition exists for what the fetch parameters indicate and which part of
the resource they are intended to delineate. Shouldn't the use of FETCH be
constrained to such media types?
So what we're missing for this to work is the equivalent of RESTCONF for
constrained nodes/networks
- Either "CoAP Management Interface", draft-vanderstok-core-comi-09 (btw
this draft expired...) - Or Constrained Objects Language,
draft-veillette-core-cool-02
Note: COMI is mentioned in the draft, but not COOL
Is this what is meant behind?
it is
outside the scope of this document how information about admissible
media types is obtained by the client
There is a clear parallel with RESTCONF (REST-like) and the CORE work:
NETMOD/NETCONF
CORE
Data Modeling Language YANG
YANG or SenML (*) Data Models YANG Module
YANG Module or SenML (*) Encoding
XML, JSON CBOR for YANG, JSON/CBOR/XML/EXI for SENML
Protocol HTTP for RESTCONF
COAP Mgmt Protocol RESTCONF/NETCONF
COMI or COOL for YANG, for SenML?? (**)
(*) not sure if SenML is a data modeling language or data models
(**) not sure if a specific mgmt protocol for SenML
Please let me know.
Regards, Benoit
I'd like to see more of the actual requirements for this draft in the security considerations as the pointers include all of the configuration options for DTLS, including the "nosec" option. I would think this operation would require authentication to prevent unauthorized access by devices that are clones. This is a real problem in the non-IoT space for firmware updates and will be a problem in this space if it isn't already - knock off hardware that installs the firmware of a popular product. In In section 5 of RFC5789, I see this: These include authorizing requests (possibly through access control and/or authentication) and ensuring that data is not corrupted through transport errors or through accidental overwrites. And would like to see something similar in this section to at least list some of the requirements and reasoning. For patch and fetch, I think the reason outlined above needs to be included as well so it is top of mind for implementers and they are aware of this very real threat. It is important they understand why they need authentication and encryption to prevent attacks against their brand. If someone buys knock-off hardware that is faulty and uses their firmware, they have multiple problems to deal with, not just the loss of sales.
I agree with Alissa and Spencer.
Sheng Jiang <jiangsheng@huawei.com> performed the opsdir review notable discussion Hi, Carsten, Thanks for clarification. I took it as that the answer for my second question is no. Then, I have no further concern. Good work. Regards, Sheng ________________________________________ From: Carsten Bormann [cabo@tzi.org] Sent: 09 October 2016 4:29 To: Sheng Jiang Cc: ops-dir@ietf.org; draft-ietf-core-etch.all@tools.ietf.org Subject: Re: OPS-DIR review of draft-ietf-core-etch Hi Sheng, thank you for your review. We don't believe there needs to be a single "standard" for the FETCH request payload media type. As the media type is somewhat specific to the kind of selection or search to be performed, as well as to the structure of the resource, more specific standards will define these media types. Please see application/cool-instance-id-list+cbor defined in https://tools.ietf.org/html/draft-veillette-core-cool-02 for just one example of such a specific definition. We have added a short note to 2.1.1 in the editors' draft to make the fact more prominent that FETCH media types are typically specifically defined. Please see https://core-wg.github.io/etch/ for the current editor's draft, to become -03 soon. Grüße, Carsten
draft-ietf-ipsecme-safecurves
- Wouldn't it be good to encourage minimising re-use of public values for multiple key exchanges? As-is, the text sort-of encourages use for "many key exchanges" in section 4. - Sorry if I'm forgetting how we handle this in IPsec, but is an implementation of this RFC expected to support both curves? I think it'd be ok to say that 25519 is a MUST for folks doing, this but that 448 is optional. I'm also fine if we mean that implementing this means you have to support both btw but you don't say (here) that that's the case.
draft-ietf-avtcore-5761-update
Thanks for doing this work, and for your response to Alissa's comment on
answer/answerer.
I did have one question - I wonder if the title
RFC 5761 SDP Offer/Answer Clarifications
might be clearer for readers who don't have RFC numbers memorized, if it was
something like
a=rtcp-mux SDP Offer/Answer Clarifications
"If the answerer includes an "a=rtcp-mux" attribute in the answer, the offerer and answerer MUST multiplex RTP and RTCP packets on a single port. If the answer does not contain an "a=rtcp-mux" attribute, the offerer and answerer MUST NOT multiplex RTP and RTCP packets on a single port." The first of these says "the answerer" and the second says "the answer." This is also how the text appears in 5761, but the difference between them caught my eye here because of the other changes being made. Is the intended meaning different between "the answerer" and the "the answer"? That is, is the implication that if the answerer include a=rtcp-mux but that somehow gets modified such that when the answer arrives at the offerer, it no longer contains a=rtcp-mux, that neither side is supposed to multiplex? This made a little more sense to me in 5761 because it was only about what the offerer should do, but now it is about what both parties should do, so I think it would help to clarify whether these two statements are both about what the answerer puts in the answer.
Rick Casarez <rick.casarez@gmail.com> provided the opsdir review
draft-ietf-webpush-protocol
Apologies if some of this is a bit wrong, I had to review this while not at a keyboard so I might make a booboo or two mapping my mental notes to text:-) Apologies also if some of the earlier discussion affects these, I didn't get a chance to check the PRs created as a result of other IESG comments. (1) This might just me being confused (in which case, sorry) but I'm not quite clear on how with works with the SOP. Given you (reasonably) recommend a different port (which is a different origin than 443) are you saying here that the SOP doesn't apply to the client? (Well, actually you don't say, so I'm not sure:-) If the SOP applies, how is the port change handled? If the SOP does not apply, then what does? (Given that I assume some UAs at least will not change their handling of the SOP no matter what we say here.) (2) So-called "capability URLs" (is that a new term here? seems like it could be the topic for a useful informational rfc) are clearly weak, but also clearly as good as we'll get for some things. However, those also become known over time, (in which case they are toast;-) so why don't you need to provide a way for a push service to say "hey, instead of <this-URL> in future you'll need to use <that-URL>"? If that could be done as an extension later, then I'd be ok with that in terms of clearing the discuss, but then I think you'd need to mention it, so that applications and UAs don't build in an assumption that these URLs are fixed for all time (while also needing to be kept "secret" as with other bearer tokens). (3) Why is it not correct to encourage mutual-auth TLS for the application to push-service connections? I'm not arguing to make that mandatory, but it's not that hard in many cases and is very useful, esp since without some client auth just knowing the URL will often enable a sender to send a crap load of updates to possibly many bandwidth/power-challenged UAs. (This is only a discuss because of that potential DoS vector.) (4) Is it really honest to say that the W3C Push API, webpush encryption and vapid are only informative references? The first seems easy to make normative, the second I think really needs to exist before we ought recommend this all get out into the wild and I'm not clear if one could sensibly make a service for this without the 3rd. Yes that might add some delay to the RFC being issued, but that might be the right thing to do. Why is it right to not wait on those two IDs and the w3c rec? This is mainly a discuss in case the answer is "we know nobody's gonna do webpush-encryption ever" in which case I'd like to be convinced that implementing and deploying based on this draft without reading those references defines a good standard. I'm not saying that it does not, I'm saying I'm not yet convinced.
- Thanks for the MUST use TLS. That's totally necessary here. (Even if maybe not sufficient:-) - I just want to check this is correct: I think it'd be potentially useful to be able to pad the traffic here with NOOP pushed messages. The argument is that the existence of a message may sometimes be the same as knowing the message content and the cost of turning on the radio to even check is no different from checking and getting a NOOP pushed message, so there's no major cost to a reasonably sized NOOP message that's only there for traffic padding. (While padding at other layers can also be done, I think we do not know enough today to say at which layers traffic padding is most useful, and we therefore ought define it where we can.) That said, I think one could later define a new "OnlyKidding" Urgency or Topic (see 9.1) that'd do the job. If that's right, consider this me asking if anyone'd like to do that later? If that's wrong, then consider this me asking: "how can I effectively pad traffic at this layer?" - section 6: (A nit) I think this could be clearer if you better explained how the subscriptions and push messages are correlated. While the current text is fine, since it's clear eventually from the examples, it might be better to not assume so much familiarity with h2.
This is generally a well written document, but I have a small list of issues (which should be easy to address) I would like to discuss before recommending its approval for publication: 1) In 5.2: is there upper limit on the TTL? The ABNF doesn't restrict the value, but it is important for interoperability 2) In 5.3: urgency is defined as a list of one or more values. The description says that it defines the lowest value allowed. There is also a sentence prohibiting multiple values. Why is this a set and how would multiple values be interpreted? 3) In 6: I don't know where the ":link" Pseudo-Header field came from. Can you clarify where it is defined?
1) <This comment was replied to. Withdrawn.> 2) In 4.1: Can 429 be used when no subscription set is specified? (If yes, this should be mentioned in section 4). 3) In 6.1: ":link" is included in the PUSH_PROMISE and not the HEADERS block (when compared to section 6). Is this intentional or should one of the examples be fixed? 4) In general case it is not possible to achieve message reliability because a push server is allowed to expire messages after they were accepted for delivery due to overload. (Similarly for forced subscription expiration.) I don't think the document makes this clear in Section 7.4. 5) <This comment was replied to. Withdrawn.>
Thanks for a well written document. I have a few questions on one topic, for which the answers may be obvious to people other than me: In section 8, 2nd paragraph: "Applications using this protocol MUST use mechanisms that provide confidentiality, integrity and data origin authentication." What must it use those mechanisms for? Are we talking about communication between the UA and app servers? Are we just talking about data in motion? As much as I like to see such requirements in general, is it reasonable for webpush to state requirements on the internal operation of the application?
Resolution of IANA's issue regarding port 1001 has been merged on git, awaiting potential further updates resulting from IESG review. https://github.com/webpush-wg/webpush-protocol/pull/133/files
Thank you for a well written security considerations section.
The only thing I might add is a note on the varying levels of security offered
by the HTTP authentication methods, which are documented in their RFCs. Adding
just that point to the following (phrased however you'd like) would be helpful:
A push service MAY
choose to authorize requests based on any HTTP-compatible
authorization method available, of which there are numerous options.
The somewhat recent updates to Basic & Digest do a really great job at saying
how awful they are and there are some experimental options that offer some
promise now.
I agree with Alexey on the "well-written document" part, but do have some minor
questions.
I noticed that
push message subscription: This resource provides read and delete
access for a message subscription. A user agent receives push
messages (Section 6) using a push message subscription. Every
push message subscription has exactly one push resource associated
with it.
and
push message: The push service creates a push message resource to
identify push messages that have been accepted for delivery
(Section 5). The push message resource is also deleted by the
user agent to acknowledge receipt (Section 6.2) of a push message.
don't say "A link relation of type ..." about the resource being defined, but
push message subscription set: This resource provides read and
delete access for a collection of push message subscriptions. A
user agent receives push messages (Section 6.1) for all the push
message subscriptions in the set. A link relation of type
"urn:ietf:params:push:set" identifies a push message subscription
set.
push: An application server requests the delivery (Section 5) of a
push message using a push resource. A link relation of type
"urn:ietf:params:push" identifies a push resource.
and
receipt subscription: An application server receives delivery
confirmations (Section 5.1) for push messages using a receipt
subscription. A link relation of type
"urn:ietf:params:push:receipt" identifies a receipt subscription.
do. Is that intentional? Or would link relation indentification not be useful
for these resources (if you told me that, I'd believe you).
I see that Topic: has no semantics, but I wonder if the example use of Topic in
Section 5.4 might be clearer if a different Topic was used - "Topic: upd" looks
like "upd" would have semantic meaning, on first reading.
I wondered why the use of subscription sets in
There are minor differences between receiving push messages for a
subscription and a subscription set. If a subscription set is
available, the user agent SHOULD use the subscription set to monitor
for push messages rather than individual push message subscriptions.
was a SHOULD, and not a MUST. Is this just an efficiency thing, or is it
something else? It would be helpful to explain this.
Is there any guidance you could give about the retry mechanism described in
this text? How many times, how often, etc.
If the push service does not receive the acknowledgement within a
reasonable amount of time, then the message is considered to be not
yet delivered. The push service SHOULD continue to retry delivery of
the message until its advertised expiration.
I'm guessing that
A push service that does not support reliable delivery over
intermittent network connections or failing applications on devices,
forces the device to acknowledge receipt directly to the application
server, incurring additional power drain in order to establish
(usually secure) connections to the individual application servers.
isn't just about "establish", but "establish and maintain"?
Maybe stupid questions: 1) Would it be possible for a user agent to use the same push service with multiple application servers? Or is this the case where a subscription set should be used? What happens in this case? Also, is there a possibility for different user agents to use the same push service if they would need to receive the same message from the same server...? Just thinking... 2) section 8.4 says: "To address this case, the W3C Push API [API] has adopted Voluntary Application Server Identification [I-D.ietf-webpush-vapid], which allows a user agent to restrict a subscription to a specific application server. " How does the user agent signal to the push service which application servers should be accepted? Did I miss that? Nit?: - In the Figure at the beginning of section 2 (which doesn't have a caption btw.) I guess you should use "application server" instead of "application" otherwise the previous definition is confusing... Also here in section 8 (s/application/application server): "This includes any communications between user agent and push service, plus communications between the application and the push service. "
Dan Romascanu <dromasca@gmail.com> provided the following opsdir review. which
should probably be followed up by the authors for editorial changes /
clarifications but which does not for me raise any show stoppers.
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 with the intent of improving the operational aspects of
the IETF drafts. Comments that are not addressed in last call may be included
in AD reviews during the IESG review. Document editors and WG chairs should
treat these comments just like any other last call comments.
This document describes protocol for the delivery of real-time events to user
agents. It uses HTTP/2 server push. It is assumed, but never explicitly stated
that at least part of the operational and manageability considerations of
HTTP/2 apply.
As this document describes a new protocol, the RFC 5707 review applies. Here is
my review, using the template described in Annex A of RFC 5706:
In what follows my comments are marked DR.
Regards,
Dan
A.1. Operational Considerations
1. Has deployment been discussed? See Section 2.1.
* Does the document include a description of how this protocol
or technology is going to be deployed and managed?
* Is the proposed specification deployable? If not, how could
it be improved?
* Does the solution scale well from the operational and
management perspective? Does the proposed approach have any
scaling issues that could affect usability for large-scale
operation?
* Are there any coexistence issues?
DR - Deployment, Scalability, Coexistence are not discussed.
2. Has installation and initial setup been discussed? See
Section 2.2.
* Is the solution sufficiently configurable?
* Are configuration parameters clearly identified?
* Are configuration parameters normalized?
* Does each configuration parameter have a reasonable default
value?
* Will configuration be pushed to a device by a configuration
manager, or pulled by a device from a configuration server?
* How will the devices and managers find and authenticate each
other?
DR - Installation and initial setup are not discussed.
3. Has the migration path been discussed? See Section 2.3.
* Are there any backward compatibility issues?
DR - not applicable, as this is a first version
4. Have the Requirements on other protocols and functional
components been discussed? See Section 2.4.
* What protocol operations are expected to be performed relative
to the new protocol or technology, and what protocols and data
models are expected to be in place or recommended to ensure
for interoperable management?
DR - yes, the protocol uses HTTP/2 push mechanisms, this is explained in detail
5. Has the impact on network operation been discussed? See
Section 2.5.
* Will the new protocol significantly increase traffic load on
existing networks?
* Will the proposed management for the new protocol
significantly increase traffic load on existing networks?
* How will the new protocol impact the behavior of other
protocols in the network? Will it impact performance (e.g.,
jitter) of certain types of applications running in the same
network?
* Does the new protocol need supporting services (e.g., DNS or
Authentication, Authorization, and Accounting - AAA) added to
an existing network?
DR - The introduction mentions optimization of traffic loads as one important
goal, but this is not sustained later. Section 6.2 mentions 'operational
constraints' with no details or explanation about what it means. Section 7.1
describes management of load, especially in what concerns the high numbers of
TCP connections.
6. Have suggestions for verifying correct operation been discussed?
See Section 2.6.
* How can one test end-to-end connectivity and throughput?
* Which metrics are of interest?
* Will testing have an impact on the protocol or the network?
DR - No. I assume operational procedures for HTTP may apply, but this is not
mentioned.
7. Has management interoperability been discussed? See Section 3.1.
* Is a standard protocol needed for interoperable management?
* Is a standard information or data model needed to make
properties comparable across devices from different vendors?
DR - No. May be not applicable.
8. Are there fault or threshold conditions that should be reported?
See Section 3.3.
* Does specific management information have time utility?
* Should the information be reported by notifications? Polling?
Event-driven polling?
* Is notification throttling discussed?
* Is there support for saving state that could be used for root
cause analysis?
DR - No. May be not applicable.
9. Is configuration discussed? See Section 3.4.
* Are configuration defaults and default modes of operation
considered?
* Is there discussion of what information should be preserved
across reboots of the device or the management system? Can
devices realistically preserve this information through hard
reboots where physical configuration might change (e.g., cards
might be swapped while a chassis is powered down)?
DR - No.
A.2. Management Considerations
Do you anticipate any manageability issues with the specification?
1. Is management interoperability discussed? See Section 3.1.
* Will it use centralized or distributed management?
* Will it require remote and/or local management applications?
* Are textual or graphical user interfaces required?
* Is textual or binary format for management information
preferred?
2. Is management information discussed? See Section 3.2.
* What is the minimal set of management (configuration, faults,
performance monitoring) objects that need to be instrumented
in order to manage the new protocol?
3. Is fault management discussed? See Section 3.3.
* Is Liveness Detection and Monitoring discussed?
* Does the solution have failure modes that are difficult to
diagnose or correct? Are faults and alarms reported and
logged?
4. Is configuration management discussed? See Section 3.4.
* Is protocol state information exposed to the user? How? Are
significant state transitions logged?
5. Is accounting management discussed? See Section 3.5.
6. Is performance management discussed? See Section 3.6.
* Does the protocol have an impact on network traffic and
network devices? Can performance be measured?
* Is protocol performance information exposed to the user?
7. Is security management discussed? See Section 3.7.
* Does the specification discuss how to manage aspects of
security, such as access controls, managing key distribution,
etc.
DR - No special problems are anticipated, but I would have expected a better
documentation on some aspects. I assume that some manageability considerations
for HTTP may apply, but this is not mentioned. The protocol uses status codes
which can be used for management purposes, but these are not exposed to users.
Load implications are discussed in section 7, how to measure load impact is not
described, it is probably assumed that HTTP load measurement applies. Securoty
and privacy are discussed in a separate section.
A.3. Documentation
Is an operational considerations and/or manageability section part of
the document?
DR - Operational considerations are described in Section 7
Does the proposed protocol have a significant operational impact on
the Internet?
DR - it may have, maybe not on the Internet as a whole, but certainly in
networks where this is deployed.
Is there proof of implementation and/or operational experience?
DR - not in the document, yes in the industry
draft-ietf-core-http-mapping
Well written doc! Thanks!
This is a generally well written document, but it seems to be defining protocol, or at least required practices for interoperability. Why is it informational? If it really does make sense for it to be informational, I think a paragraph explaining why would be helpful. The 2nd paragraph in section 1 seems to attempt that, but the explanation leads me again to think that informational is not the right status. "Guidelines that...should adhere to" to increase interoperability doesn't sound informational.
Larry Masinter promised Apps-Dir review, but he hasn't done it yet.
Thanks for addressing my DISCUSS and COMMENTs.
[sorry for coming late to the party] One point I would like to DISCUSS: I wonder if this document is not already obsolete, now that we have the new FETCH/iPATCH/PATCH methods (draft-ietf-core-etch)? Should we expect an update document for the new mappings? Don't we need at least a reference to draft-ietf-core-etch, expressing it's not covered?
Thank you for addressing my discuss points with the proposed text. I'll follow along with Stephen's discuss as he picked up on some other important points.
Thanks for addressing my Discuss and comments. For what it's worth, I also like the changes you made to address other feedback, too.
I don't get why you don't at least RECOMMEND that HTTP requests need to be authenticated? And I don't get why you don't REQUIRE HC implementations support some form(s) of strong-ish user authentication. We are seeing fairly major botnets being built from the kinds of device that might use CoAP and (with careless implementations all around) this could provide a nice way to expose those to the Internet. Isn't a good bit more caution needed in what we describe here? Note: I'm not saying HTTP authentication, nor specifically TLS client auth.
Generally, I'd have been happier if this document went more towards reducing the attack surface and seemed less keen on being more flexible. I assume though that the WG considered that. (Some specific places that occurred to me are noted below.) I also agree with Kathleen's discuss. - 6.1: "free to attempt mapping a single Accept header in a GET request to multiple CoAP GET requests" - does that provide a potential way to DoS (e.g. battery depletion) devices in the constrained network? If so, would a warning be useful? E.g. to limit the number of times a given media type is attempted. - 6.1: What "other forms of access control" do you mean? - 6.2: This looks like it allows too large an attack surface and maybe you ought default to denying - 6.5: Transcoding bugs galore! Given the history of bugs in transcoding libraries shouldn't you recommend some caution here? And are there forms of zipbomb that might cause problems? - 8.2: The presentation of the formula is not clear to me. You say "reduces M_R iff..." but that's not a clear "method to decide" as promised. - 10.3: In practice, what does "other means" mean in "This recommendation may be relaxed in case the destination network is believed to be secured by other means." ?
מנחם דודג' <menachemdodge1@gmail.com> performed the opsdir review
draft-ietf-lisp-crypto
Thanks for doing this. Great to see folks incorporating such things where we can and I'll be interested to see how the experiments with this pan out. - intro: (nit) "PKI infrastructure" - the I in PKI already means infrastructure:-) - intro: (another nit) I don't get why " o Packet transport is optimized due to less packet headers. Packet loss is reduced by a more efficient key exchange." is true. - 3: (more nittyness:) AEAD is defined in RFC5116. - section 6 non-nit: I don't see why you want cipher suites 1, 2 and 4. The set of 3,5 and 6 seems to me like it'd be plenty. If it's not too late, I'd encourage you to either drop 1,2 and 4 or say those are OPTIONAL and 3,5 and 6 are RECOMMENDED. - section 7: I think you should embed the KDF into the cipher suite. It's ok to only have one KDF now, but later you may want others and it's fairly easy to include the KDF as part of the definition of the ciphersuite. - section 7: Why didn't you choose RFC 5869 for the KDF? That's a more accessible reference I think and just as good.
Thank you for this document. I would like to double check that I understand the document correctly. Is the following scenario possible: ITR requests negotiation of 3 keys, then in a later request ITR can request change to 1 (or 2) of the keys, while continuing to use the remaining keys?
Section 12.1 seems unnecessary.
Thanks for your work on this draft. I think the draft would read better if the content of the Abstract is repeated in the introduction. If you read just the introduction, it is not clear what this draft is about, the abstract text is needed to have an understanding. In the introduction, I'm not sure what this means: Packets that arrive at the ITR or PITR are typically not modified, which means no protection or privacy of the data is added. Do you mean modified as in 'not encrypted' or something else? It would be easier to read if what you meant was clearly stated. It's followed by this sentence: If the source host encrypts the data stream then the encapsulated packets can be encrypted but would be redundant. But the introduction doesn't clearly say what this would be redundant to. Can you clarify this text too? Thanks for addressing the SecDir review. https://www.ietf.org/mail-archive/web/secdir/current/msg06835.html
Susan Hares <shares@ndzh.com> provided the opsdir review
draft-ietf-lisp-lcaf
The way that the length field is specified in this document is inconsistent, extremely confusing and sometimes wrong. e.g. In Section ASCII Names in the Mapping Database Length value n: length in bytes AFI=17 field and the null-terminated ASCII string (the last byte of 0 is included). but the field mentions 2+n. Only one of these can be correct Similarly in Section 4.9. Replication List Entries for Multicast Forwarding Length value n: length in bytes of fields that follow. but the field mentions 4+n. Again one of these can be correct. Similar error in Section 5.2 (Generic Database Mapping Lookups) * Section 4.10.4. Using Recursive LISP Canonical Address Encodings The "IP TOS, IPv6 QQS or Flow Label" field is underspecified and cannot be implemented in an interoperable manner. There are multiple ways to encode the 8 bit values (the IP TOS and the IPv6 Traffic Class) into the 24 bit field. Similarly, there are at least two obvious ways to encode the 20 bit flow label into this field. Also the "IPv6 QoS" needs to be renamed to "IPv6 Traffic Class"
* Can you please clarify why Rsvd2 is reserved for future use but this document
already ends up specifying it under "Segmentation"
* I think the reference for AFI is not correct. Shouldn't it be
http://www.iana.org/assignments/address-family-numbers/address-family-numbers.xhtml? The current reference leads to a generic IANA page.
* Section 4.8:
Is the explanation for the AFI correct? The source dest lookups don't seem to
be multicast addresses.
"When a specific AFI has its own encoding of a multicast address, this field
must be either
a group address or a broadcast address."
To IESG: Is this just me or do other people find it to be quite confusing why information such as URIs and JSON blobs can be included in LISP mapping database? I admit that this might be just my ignorance of LISP, but the document Introduction (or Abstract) doesn't explain the need.
Dns names and URIs need normative references.
Section 4.3 talks about geo coordinates. I think I understand that these coordinates may give the location of a device. Is there any expectation that said device can be associated with a person? The security considerations mention this briefly. Have the working group considered whether the guidance in RFC 6280/BCP 160 is applicable here?
Thanks for writing this doc. I plan to recommend its approval, but there were a couple of things that I think should be fixed for clarity before issuing the RFC. First, I agree with Peter Yee who did a Gen-ART review on this document: > Page 6, Rsvd2 definition: the definition both says "reserved for future use" > and then says some types actually use it. That sounds like present use. > And to generically say that it should be sent as zero and ignored, but then > to give uses (such as Type 2) for it is confusing. I suggest rethinking > the wording here. The type that seems to differ from the "ignore" advice in Section 3 is Type 14. Perhaps you can reword somehow, or name the Rsvd2 field to Flags, and let the Subsections define that as "set to 0 and ignore on receipt". Or something along those lines? I also agree with this comment and believe the text should be corrected: > Page 6, Length definition: there's mention of a "Reserved" field that's > included in the minimum length of 8 bytes that are not part of the length > value. Since there are actually Rsvd1 and Rsvd2 fields in the generic > version of the LCAF and sometimes even Rsvd3 and Rsvd4 fields when using > specific Types, it might be better to spell out which reserved fields (Rsvd1 > and Rsvd2) are meant here rather than giving the field a summary name that > doesn't actually appear in the format. This is also important because any > Rsvd3 and Rsvd4 fields are included in the Length field, so using a generic > "Reserved" description is ambiguous at best. And this seems like a bug as well: > Page 13, RTR RLOC Address definition, 4th sentence: The ability to determine > the number of RTRs encoded by looking at the value of the LCAF length > doesn't seem feasible. 3 IPv4 RTR RLOCs will produce the same LCAF Length > as 1 IPv6 RTR RLOC.
Subsections under Section 4 treat some of the fields in different ways. For
instance, in most cases the subsections do not indicate anything about the base
fields, but for instance Subsection 4.9 does say something about Rsvd1 and
Rsvd2:
Rsvd{1,2,3,4}: must be set to zero and ignore on receipt.
This text was raised as an issue by Peter as well:
When there are no RTRs
supplied, the RTR fields can be omitted and reflected by the LCAF
length field or an AFI of 0 can be used to indicate zero RTRs
encoded.
Why are we giving two options? Or is this a
be-conservative-what-you-send-but-liberal-in-what-you-accept situation?
Sarah Banks <sbanks@encrypted.net> reviewed this document for the opsdir
conflict-review-irtf-cfrg-eddsa
I am not sure whether or not I should recuse myself, as this is CFRG document which I co-chair.