jiebi/CodeConvo huggingface dataset:
-semantics gives the answer to this: you MUST NOT emit (§ 2.2), but as a receiver you are cautioned that (§ 2.3): Additionally (§ 2.4): This gives you the permission you want: you are encouraged to parse the field defensively and you may attempt to recover, which implies that by default you may fail, and that -semantics does not specify exactly how you will handle these failures. HTTP/2 continues to grant your application that freedom. The specification does not bind you: you can handle this as you want.
OK True. Which is actually worse, as it leaves the set of undefined other than we know it is a subset of the compliment of the set of invalid fields define here. Also worse, as it means the document only vaguely defines validity. There is actually no definition of what is a valid h2-field. This reason could be used to say that there should be no additional invalidity check in this document. Just allow any hpack-valid field and leave the rest to be a matter of semantics. The fields excluded by this definition are only dangerous if forwarded, which is already covered by "Intermediary Encapsulation Attacks" section that suggests that full HTTP ABNF grammar should be applied (in addition to the vaguely defined exclusions of "HTTP Fields"). So I'm back to why is this document in-precisely defining valid/invalid h2-fields. It is not for intermediaries as there is a section in the document dedicated to that. It is not for locally interpreted HTTP as you say HTTP semantics should be applied. Why does this document say that a field name containing space is invalid, yet one containing a double quote is not? Neither are valid HTTP, both are valid hpack. There is no good reason I can see for either and whilst I don't know of any specific attack that either could be used for, I would not be surprised if both could be used to some evil ends. This vague definition is going to have a significant carbon footprint.
Many Implementations will ultimately end up double validating field names: once to exclude the s in their h2 layer and then later in their semantic layer to include only the s. Double validation could be avoided if this document either didn't restrict field validity or precisely defined valid fields as a subset of s so that semantic layers could trust the fields received from their h2 layers as being valid HTTP. Maybe there is a reason for this double validation and the resulting CPU cycles, but I have yet to see why validity is only partially defined.
It suggests it but does not require it. The other text requires validation. Most intermediaries will not apply the full ABNF validation because a) it requires perfect understanding of the ABNF of all header fields, which they will not have, and b) even if they did, the -semantics ABNF is sufficiently costly to validate that they won't do it. Cheaper validation steps are more likely to be implemented. This document (and -semantics) is imprecisely defining them because a . The ABNF you're citing represents, fundamentally, guidance. If you want to reject things that don't conform to the ABNF you are free to do so (as -semantics says), but there is no document that obligates you to reject them. This is deliberate, because there is (IMO) absolutely no point in adding normative requirements that, if followed, would harm interoperability. In this case the document is calling out specific cases that MUST be rejected. Practically speaking the intention of this is to encode requirements from other messaging formats, such as -messaging, to ensure that HTTP/2 implementations do not encode header fields that cannot be safely translated to HTTP/1.1. This provides a lower bound on validation: so long as everybody does this, we can safely rely on HTTP/2 messages being represented in HTTP/1.1's framing. Note that this doesn't meant they'll be valid HTTP/1.1 messages, just that they are not going to parse incorrectly. With that in mind, the constraints added here are, in order: A cheap bitwise check that can be safely vectorised and applied to reject most invalid field names. This is sufficient to get close to the ABNF, but is cheaper. A check that reserves pseudo-headers and is a single-byte comparison.
Three vectorizeable field-value checks (NUL, LF, CR) all ensuring valid HTTP/1.1 framing. 4 single-byte comparisons against the first byte of the field-value. This problem is solved by not doing that. The ABNF in -semantics, if enforced, is a strict superset of the requirements here except for (2). If your implementation will enforce the requirements in -semantics, you can choose to not enforce these ones at the h2 layer, knowing that the -semantics layer will cover you. The RFC does not bind your implementation, only your observable behaviour: if your implementation ends up rejecting header fields that meet these characteristics, it doesn't matter why you did it, only that you did.
I don't get that. We're still talking about field names, right?
No, all of this applies to names and values:
Well. Validating names and values are very different things. It would be best to clearly separate these topics.
I get it that there is a minimum standard being set. In section "HTTP Fields" it says that h2 implementations MUST treat as malformed any fields that violate any of the described conditions and an intermediary MUST NOT forward any such headers. Then again in section "Intermediary Encapsulation Attacks" is says the validations of the "HTTP Fields" MUST be implemented, which is kind of a duplication as they are already at MUST strength. I don't see any normative text that says that an implementation MAY or SHOULD validate against the HTTP ABNF and that if they do so then that is a superset of the conditions in section "HTTP Fields" I would very much prefer to see text in the "HTTP Fields" section that clearly says h2 implementations MAY validate against the HTTP ABNF and that any implementations that do not MUST validate fields against the following conditions. I'll have a try at this later today.... stand by....
NAME I'm reading your comments as supportive of the technical change, but a strong preference for a different way of presenting the information. I want to clarify that this change is about the mandatory validation that endpoints perform on fields. It looks like we all agree with stipulating a minimum amount of validation that applies to all implementations, especially those that would otherwise just forward fields without processing.
Additionally, we all agree that additional validation is permitted, up to the point that knowledge of the semantics for the fields is applied in validating the values. Where we might disagree is in the way that these requirements are described. I've chosen to use words; NAME would prefer ABNF. As we agree on the technical substance and the question of presentation is an editorial decision in which Cory and I have discretion I'm going to merge this pull request. We would like to publish a revision ahead of the upcoming interim. If you disagree with this decision, especially the technical aspects, then I encourage you to open a new issue. One aspect that seems like it might worth discussing is whether we encourage additional validation rather than simply permitting it. That is, "SHOULD/MAY fully validate".
NAME that's a correct summation of my position. I would have preferred that some text for SHOULD/MAY fully validate to be resolved in this PR (with or without ABNF), but will open another issue.
: While most of the values that can be encoded will not alter header field parsing, carriage return (CR, ASCII 0xd), line feed (LF, ASCII 0xa), and the zero character (NUL, ASCII 0x0) might be exploited by an attacker if they are translated verbatim. Any request or response that contains a character not permitted in a header field value MUST be treated as malformed (Section 8.1.2.6). Valid characters are defined by the "field-content" ABNF rule in Section 3.2 of [RFC7230]. There are multiple issues here: it's confusing to say "HTTP/2 allows" when next they are actually forbidden with a MUST requirement; it might be better to say something like that the wire protocol in theory enables the transmission of these forbidden characters this puts a normative requirement on top of the base spec; but so does the revision of the core specs (see URL). We need to make sure that there are no conflicting requirements. It also should be checked whether the currently present requirements are actually implemented in UAs (and if they are not, what could be done about it)
It would presumably be more accurate to say that "HPACK allows", right?
HPACK also allows encoding a field line with an empty name. I'm not sure this needs to be mentioned explicitly or not.
Well, that's consistent with HTTP/1.1 :-)
I hate having to do this, but what is possible and what is permissible need to be more clearly separated.
I'm going to tag this as editorial: the possible/permissible split is clearly editorial. And we've decided to depend on the core docs, and whether or not it was clear before what was allowed or not, this is now very crisp in the core semantics. I want to wait until we get in before doing this though.
Discussed in the context of leading and trailing whitespace in -semantics. I think that we should be clearer here about a few things: CRLF and NUL are strictly prohibited leading and trailing WS are strictly prohibited Maybe loosen the requirement a little so that it is less strict about adherence to the ABNF That makes this non-editorial, I think.
This is the one case in Jörg's review where I think we need text. In the other places, the text is secondary to other normative language and should not be restated in direct terms (or it would need to be far more precise than it is). For .
[x] Section 5.1.1., 3rd para: When a stream transitions out of the "idle" state, all streams that might have been initiated by that peer with a lower-valued stream identifier are implicitly transitioned to "closed". Should one say "that might have been but were not initiated by that peers" to make clear that this applies only to un-used streams? [x] Section 5.3.1 Maybe update the section heading to read "Background on Priority in HTTP/2 as per RFC7540"? [x] Section 6.5: The document implies that SETTINGS frames are ACKed in the order they are sent. Should one make this explicit? [x] Last para of 6.5, top of page 37: "If the sender of a SETTINGS frame does not receive an acknowledgement within a reasonable amount of time, it MAY issue a connection error (Section 5.4.1) of type SETTINGSTIMEOUT." Should one provide some intuition on what "reasonable" could mean? An example? It seems, an HTTP/2 sender of a SETTINGS frame could know when this was passed to the TCP layer and may have some insights on application layer RTTs. [x] Section 6.9.1: Concerning flow control, should one say something about avoiding silly windows? [x] Section 8.1.1, p52 1st para: Probably just me, but I am mildly confused by the statement about messages having a non-zero content-length field but still no data in the data frames. The reference section 6.4 of the HTTP semantics draft didn't resolve that. [x] Section 8.2.1, p53: parse error?
"When a request message violates one of these requirements, an implementation SHOULD generate a Section 15.5.1 of 400 (Bad Request) status code [HTTP], [...]" [x] Section 8.4.2, 4th para: "A client can use the SETTINGSMAXCONCURRENTSTREAMS setting to limit the number of responses that can be concurrently pushed by a server. Advertising a SETTINGSMAXCONCURRENTSTREAMS value of zero disables server push by preventing the server from creating the necessary streams. This does not prohibit a server from sending PUSHPROMISE frames; clients need to reset any promised streams that are not wanted. Confused: it disables server push, but the server can send PUSHPROMISE frames and then the client is supposed to reset a stream it wasn't willing to accept or capable of accepting? Which stream number would the server legitimately put into the PUSHPROMISE? [ ] There are a few cases where I am wondering if normative language should be used. Examples include [ ] -- 5.4.2, 2nd para, "sends an RST_STREAM frame" [x] -- 6.8, p43, 1st para, "the server can send another GOAWAY" [ ] -- 6.8, p43, 2nd para, "the sender can discard frames" [ ] -- 9.1, 3rd para, "clients can create" [ ] There may be further occurrences of "can" or similar.
FYI NAME I've updated this post to have a list of checkboxes for "addressed".
I've reviewed the changes here and I'm happy with 9/14. The others I don't think need to be addressed.
In some use cases of SD-JWT, the key for what we currently call Holder Binding may not be bound to a holder (but, for example, to a device). We should therefore consider renaming Holder Binding to Key Binding.
PRs have been merged
The spec currently does not contain a reference for RFC 7519 (JWT), which it clearly needs to. It also uses RFC 7515 (JWS) as the citation for JWT in several place, which is incorrect. Please add a RFC 7519 (JWT) reference and cite it the first time that the term JSON Web Token (JWT) is used in the body of the spec (but not in the abstract). And look at the current uses of RFC 7515 and correct those that should be RFC 7519.
NAME or NAME , can you merge this (now-updated) PR, or give me write access so I can do this ;-) ?
I don't know how to give you write access, so I merged it. :)
Based on the original comment: URL and the response: URL it is proposed to add requirements for the stub router behavior on the AIL regarding: advertising itself as a default router on the AIL; advertising a default route on the AIL. For correct operation the stub router MUST NOT advertise both of these. While Section 5.4 has requirements for default router/route advertising on the stub network, there is no section yet with specific requirements for the AIL side. This needs to be added. (FYI NAME
See also some more detailed suggestions at the bottom of mail: URL
This issues was self-assigned to NAME Hi, That was the case in the past, but RFC 6724 introduced a "label" for ULA that is distinct from GUA. Since matching labels are preferred, the match between two IPv4 addresses (one label for IPv4) is preferred over the mismatched labels of GUA and ULA. There is another possible failure case, when a remote ULA is received via DNS although the traffic would have to go via Internet. This case is solved in RFC 6724 by specifying a lower "precedence" for ULA than for IPv4. (Not all hosts implement the latter part, e.g., GNU/Linux has a higher preference for ULA than for IPv4.) That should work, but RFC 4191 states that in section 4: "When ceasing to be an advertising interface and sending Router Advertisements with a Router Lifetime of zero, the Router Advertisement SHOULD also set the Route Lifetime to zero in all Route Information Options." RFC 4861 describes in section 6.2.3: "A router might want to send Router Advertisements without advertising itself as a default router. For instance, a router might advertise prefixes for stateless address autoconfiguration while not wishing to forward packets. Such a router sets the Router Lifetime field in outgoing advertisements to zero." So using a router lifetime of 0 does not imply that the interface is not an advertising interface. This combination does not seem obvious to me, but it seems valid.
Going back to RFC 4191, section 5.2 mentions the combination of router lifetime 0 with RIOs with lifetime > 0 as a solution for type C hosts. The solution for type B hosts for a single isolated network is preference based, and there is no solution for type A hosts. I think that Route Information Options should be accepted from RAs with a Router Lifetime of 0 according to those RFCs. Yes, several stub routers each using each others as Internet gateways would not work. Thus I think that stub routers must not advertise themselves as default routers on the AIL. Perhaps this could be made explicit? I would like the draft to be explicit regarding RA contents, preferably with a rationale. I would really like to read short explanations for the specific settings, i.e., how this is supposed to work. It would be great if draft-ietf-snac-simple could mention section 5.2 of RFC 4191 and that a lifetime of 0 should suffice for type A and B hosts to ignore the stub router, i.e., do no harm, but a type C host is required for stub network reachability from the host. Since supporting a type B host would risk creating problems for a type A host, I would prefer SNAC to only work for type C hosts. As soon as more than one stub network is connected to the AIL, only type C hosts can reliably choose the correct stub router anyway. The case of multiple stub networks is more complex than the scenario from RFC 4191 section 5.2. Best regards, Erik A distributed system is one in which the failure of a computer you didn't even know existed can render your own computer unusable. -- Leslie Lamport
Hello, I can try to respond from my viewpoint. This could help to identify the open issues. I don't see how RFC 8028 is relevant here. It has the following applicability: IPv6 host in a network that has more than one prefix, each allocated by an upstream network that is assumed to implement BCP 38 [RFC2827] ingress filtering The network/link (AIL) considered for SNAC-simple is a link with a single IPv6 on-link prefix. Either a global/ULA prefix allocated by e.g.
a home router, or if that is missing, a ULA prefix allocated by one of the stub routers. So there's not "more than one prefix" and I don't see immediately if any problem would occur if we would have > 1 prefix. For example the IPv6 host on the AIL would remain reachable from an on-stub-network host, regardless of the IPv6 source address that the host on the AIL used. See also below for more info on this case for the packets in the other direction. This part I agree should be clarified in SNAC-simple. I assumed a Type C host for sure. And I would consider Type A and Type B to be even out of scope if required to keep the solution simple! One question is: what if a Type A/B host sent an IPv6 packet to the ULA dest address of a stub-Host ; and the packet would be routed to the default router of the home network? (E.g. home router / Wi-Fi AP / ISP box) Wouldn't that default router immediately discover that the correct route is to send it to the stub router, based on the RA RIO advertisements? So the routing is not most efficient then but it works. If that is the case, we can still support Type A/B hosts although with some degraded performance/latency. I think we could clarify that the stub router must never ever advertise itself as a default router (or advertise a default route ::/0) on the AIL. This isn't in the draft yet. Not sure if that is what you meant here? The existing mentions of "default route(r)" in SNAC-simple are pertain to advertising itself as default route on the stub network side, not the AIL side, I believe. Given the above, even if the host would not follow rule 5.5, it would pick another source address, but still that address would be based on an IPv6 prefix that is on-link. So it means the stub router can correctly route back to that prefix and use IPv6 ND to find the host back on the link. And the IPv6 host if it is type C would still use the RA RIO advertisements to pick the next-hop router, regardless of its IPv6 source address.
The only question I have is for the Type A/B hosts - they might pick a default router instead and the question is there if it would route back the packet to the right stub router on the AIL instead of sending the packet out onto the wider Internet. (My expectation is that it would work, but ... ) But this Type A/B host problem is there independent of the source address selection. Or am I missing something? Also keep in mind that there are in total 3 possible cases for a given stub router: Stub router uses its generated ULA prefix to assign a prefix for the stub network; and also to assign a prefix for the AIL. Stub router uses its generated ULA prefix to assign a prefix for the stub network; but another stub-router (there may be N stub routers in total, each with a different stub network) has assigned the AIL prefix. That means the prefixes don't use a shared ULA prefix. Stub router uses its generated ULA prefix to assign a prefix for the stub network; but another non-stub-router (e.g. home AP) has already assigned a prefix for the AIL. That means the prefixes don't use a shared ULA prefix. So we cannot rely on features that only work well when a single ULA prefix is used to derive the AIL on-link prefix and the stub network on-link prefix. Esko -----Original Message----- From: Snac On Behalf Of Erik Auerswald Sent: Sunday, August 20, 2023 20:24 To: SNAC List Subject: [Snac] Host Requirements for SNAC Use? Hello SNAC WG, when looking at the basic idea of connecting a stub network via stub router to an existing link (the AIL), in general a host on the AIL would need to use the stub router as gateway to reach the stub network. If this host already has IPv6 connectivity to the Internet, the stub router may be added to that list. Now the host needs to determine which gateway to use for a given packet. Both the IETF Proposed Standard RFCs and existing host implementations allow to choose the wrong gateway, i.e., a gateway that does not have a next-hop to deliver the packet. It seems to me as if some assumptions beyond the most minimal IPv6 host implementations are required to connect a stub network via stub router without additional configuration.
RFC 8504 (BCP 220) requires adherence to RFC 4191 which describes three host types called A, B, and C. Only type C hosts can reliably choose the correct gateway. BCP 220 also recommends (but does not require) adherence to RFC 8028 for first-hop router selection. Among other contents, RFC 8028 recommends use of RFC 6724 section 5 rule 5.5. If the host behaves like a type C host from RFC 4191, and the stub router advertises the stub prefix(es) as off-link, the host chooses the stub router to reach the stub network. If the stub router also uses a low default router preference there is some chance that the host will not use it to reach destinations not on the stub network. Perhaps this could be added to draft-ietf-snac-simple? If the host conforms to RFC 6724, and follows RFC 6724 section 5 rule , and it implements the procedure described in RFC 6724 section 10.6, and the stub router advertises a ULA prefix as on-link on the AIL, and the stub network uses ULAs from the same 48-bit global ULA prefix as advertised by the stub router on the AIL, then the host will use the stub router to reach the stub network, and will not use it to reach other destination. Perhaps this could be added to draft-ietf-snac-simple? Since a host may decide to send packets for destinations off the stub network to the stub router, it might be a good idea to require the stub router to forward such packets to a default router detected on the AIL (e.g., via RA). If there is no IPv6 default router on the AIL, the stub router should make it likely that connecting it does not break IPv4 connectivity to the Internet. If the host conforms to RFC 6724, use of ULAs by the stub router suffices. This, of course, means that the RFC 6724 preference of IPv4 over ULA is required for safe stub router use. Perhaps this could be added to draft-ietf-snac-simple? Best regards, Erik Inside every large problem is a small problem struggling to get out.