jiebi/CodeConvo huggingface dataset:
Code change:
make these POST requests from the domain on which the script is executing.  (See cors for additional details.) <del> All precautions MUST be taken to prevent XSS attacks. </del> <ins> Besides the general risks of XSS, if tokens are stored or handled by the browser, XSS poses an additional risk of token exfiltration.  In this architecture, the JavaScript application is storing the access token so that it can make requests directly to the resource server. There are two primary methods by which the application can store the token, with different security considerations of each. </ins> <del> In general, cross-site scripting (XSS) attacks are a huge risk, and can lead to full compromise of the application.  If tokens are ever stored or handled by the browser, XSS poses an additional risk of token exfiltration.  In this architecture, the JavaScript application is storing the access token so that it can make requests directly to the resource server.  There are two primary methods by which the application can store the token, with slightly different security considerations of each. 6.3.1. </del> <ins> 6.4.1. </ins> If the JavaScript in the DOM will be making requests directly to the <del> resource server, it will need to store the tokens somewhere accessible to the DOM.  In the case of a successful XSS attack, the injected code will have full access to the stored tokens and can exfiltrate them to the attacker. </del> <ins> resource server, the simplest mechanism is to store the tokens somewhere accessible to the DOM.  In the case of a successful XSS attack, the injected code will have full access to the stored tokens and can exfiltrate them to the attacker. </ins> <del> 6.3.2. </del> <ins> 6.4.2. </ins> In this scenario, a Service Worker [1] is responsible for obtaining tokens from the authorization server and making requests to the

Related discussion:
text: I moved the considerations about XSS to a general section: all architectures are concerned. I added some words about bypassing the Service Worker: this would need a very broad successful XSS, with a much broader attack surface than what is typically the case. This can be mitigated by making sure that registering the service worker is the very first thing happening. There is also no API for unregistering a SW, so it can't be removed after the fact.
I haven't dug too deep yet but isn't this an API to unregister a service worker? URL
Indeed, this mitigation won't work. I oversaw the registration itself and focused on URL . I'll rework this and focus on what can be guaranteed by specs.
I removed the part about service workers for now. I'll see if I can further improve it in another PR.
Code change:
a header table and a reference set.  Everything else is either immutable or conceptual. <del> Using HTTP, messages are exchanged between a client and a server in both direction.  To keep the encoding of header fields in each direction independent from the other direction, there is one encoding context for each direction. The header fields contained in a PUSH_PROMISE frame sent by a server to a client are encoded within the same context as the header fields contained in the HEADERS frame corresponding to a response sent from the server to the client. </del> <ins> HTTP messages are exchanged between a client and a server in both directions.  The encoding of header fields in each direction is independent from the other direction.  There is a single encoding context for each direction used to encode all header fields sent in that direction. </ins> 3.1.2.

Related discussion:
text: Editorial changes through Section 3.1.2. Further updates forthcoming.
Rebased onto current master.
Code change:
Each stub network will have some set of prefixes that are advertised as on-link for that network.  A stub router connected to that stub network SHOULD advertise reachability to all such prefixes on any AIL <del> to which it is attached using router advertisements </del> <ins> to which it is attached using router advertisements. A stub router SHOULD NOT advertise itself as a default router on an AIL by setting a non-zero Router Lifetime value in the header of its Router Advertisements.  The exception to this rule is the case where the stub router itself is the default router for a particular AIL: for example, it may be the home router providing connectivity to an ISP. </ins> 5.4.

Related discussion:
text: 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.
Code change:
Each stub network will have some set of prefixes that are advertised as on-link for that network.  A stub router connected to that stub network SHOULD advertise reachability to all such prefixes on any AIL <del> to which it is attached using router advertisements </del> <ins> to which it is attached using router advertisements. A stub router SHOULD NOT advertise itself as a default router on an AIL by setting a non-zero Router Lifetime value in the header of its Router Advertisements.  The exception to this rule is the case where the stub router itself is the default router for a particular AIL: for example, it may be the home router providing connectivity to an ISP. </ins> 5.4.

Related discussion:
text: 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.
Code change:
Each stub network will have some set of prefixes that are advertised as on-link for that network.  A stub router connected to that stub network SHOULD advertise reachability to all such prefixes on any AIL <del> to which it is attached using router advertisements </del> <ins> to which it is attached using router advertisements. A stub router SHOULD NOT advertise itself as a default router on an AIL by setting a non-zero Router Lifetime value in the header of its Router Advertisements.  The exception to this rule is the case where the stub router itself is the default router for a particular AIL: for example, it may be the home router providing connectivity to an ISP. </ins> 5.4.

Related discussion:
text: 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.
Code change:
Each stub network will have some set of prefixes that are advertised as on-link for that network.  A stub router connected to that stub network SHOULD advertise reachability to all such prefixes on any AIL <del> to which it is attached using router advertisements </del> <ins> to which it is attached using router advertisements. A stub router SHOULD NOT advertise itself as a default router on an AIL by setting a non-zero Router Lifetime value in the header of its Router Advertisements.  The exception to this rule is the case where the stub router itself is the default router for a particular AIL: for example, it may be the home router providing connectivity to an ISP. </ins> 5.4.

Related discussion:
text: 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.
Code change:
Each stub network will have some set of prefixes that are advertised as on-link for that network.  A stub router connected to that stub network SHOULD advertise reachability to all such prefixes on any AIL <del> to which it is attached using router advertisements </del> <ins> to which it is attached using router advertisements. A stub router SHOULD NOT advertise itself as a default router on an AIL by setting a non-zero Router Lifetime value in the header of its Router Advertisements.  The exception to this rule is the case where the stub router itself is the default router for a particular AIL: for example, it may be the home router providing connectivity to an ISP. </ins> 5.4.

Related discussion:
text: 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.
Code change:
Each stub network will have some set of prefixes that are advertised as on-link for that network.  A stub router connected to that stub network SHOULD advertise reachability to all such prefixes on any AIL <del> to which it is attached using router advertisements </del> <ins> to which it is attached using router advertisements. A stub router SHOULD NOT advertise itself as a default router on an AIL by setting a non-zero Router Lifetime value in the header of its Router Advertisements.  The exception to this rule is the case where the stub router itself is the default router for a particular AIL: for example, it may be the home router providing connectivity to an ISP. </ins> 5.4.

Related discussion:
text: -- Hoare's Law of Large Problems Snac mailing list EMAIL URL
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?
Code change:
Each stub network will have some set of prefixes that are advertised as on-link for that network.  A stub router connected to that stub network SHOULD advertise reachability to all such prefixes on any AIL <del> to which it is attached using router advertisements </del> <ins> to which it is attached using router advertisements. A stub router SHOULD NOT advertise itself as a default router on an AIL by setting a non-zero Router Lifetime value in the header of its Router Advertisements.  The exception to this rule is the case where the stub router itself is the default router for a particular AIL: for example, it may be the home router providing connectivity to an ISP. </ins> 5.4.

Related discussion:
text: 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. -- Hoare's Law of Large Problems