Thank you Kyle. I'll cross-post here my hats-off comment from the related github issue. """ Enforcing by IP Prefix, where prefixOf(IPv4 address) == /32 and prefixOf(IPv6 address) <= 64, seems likely to be simple for both enforcement and API endpoints (where separate). We can generally depend on return routability as part of connection establishment to address spoofing. In the futuristic case of a QUIC-enabled API endpoint it might well be possible to issue some commands within a single packet sans return routability. At the moment the API doesn't really let you do any damage, but this is stuff we should have documented in the relevant security sections. Lastly, my biggest remaining concern is that folks might erroneously assume that "IPv6 == 128bit IPv4", which is just not true (as we know, but some readers might not). If we were to see deployment of enforcement points that didn't allow clients to form new IPv6 addresses on the same link and use them freely (i.e. without re-authenticating) then that could be seen as violating the spirit of RFC 7934 (and generally be bad for the IPv6 Internet). I can already imagine the defensive code in Android to use a new IPv6 address for every captive portal API call, just to be sure. :-/ """ On 5 March 2018 at 01:51, Kyle Larose <[email protected]> wrote: > Issue number 5 (https://github.com/capport-wg/architecture/issues/5) against > the captive portal architecture raises the question of which portion of the > packet to use for capport enforcement. I have uploaded a change to the > architecture repo to attempt to address this issue: > https://github.com/capport-wg/architecture/pull/9. > > Feel free to read over the pull request and give feedback. > > Thanks! > > Kyle > > Disclaimer: > This communication (including any attachments) is intended for the use of > the intended recipient(s) only and may contain information that is > considered confidential, proprietary, sensitive and/or otherwise legally > protected. Any unauthorized use or dissemination of this communication is > strictly prohibited. If you have received this communication in error, > please immediately notify the sender by return e-mail message and delete all > copies of the original communication. Thank you for your cooperation. > > > _______________________________________________ > Captive-portals mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/captive-portals >
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature