[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Captive-portals] Which portion of packet is used for capport enforcement?

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