Send dhcp-users mailing list submissions to
        dhcp-users@lists.isc.org

To subscribe or unsubscribe via the World Wide Web, visit
        https://lists.isc.org/mailman/listinfo/dhcp-users
or, via email, send a message with subject or body 'help' to
        dhcp-users-requ...@lists.isc.org

You can reach the person managing the list at
        dhcp-users-ow...@lists.isc.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of dhcp-users digest..."


Today's Topics:

   1. RFC 8910 (?n?rant)
   2. Re: RFC 8910 (perl-list)
   3. Re: RFC 8910 (?n?rant)


----------------------------------------------------------------------

Message: 1
Date: Wed, 20 Apr 2022 16:04:00 +0200
From: ?n?rant <yner...@crans.org>
To: dhcp-users@lists.isc.org
Subject: RFC 8910
Message-ID: <90d1868be7901cd72bcecc7ce31632969ade8d8e.ca...@crans.org>
Content-Type: text/plain; charset="utf-8"

Hello!

For my organization, I am using isc-dhcp-server as DHCP server.

We want to deploy a captive portal for a new open Wifi to authenticate
users. However, we want to do it great, and avoid to do Man-in-the-
middle attacks to access the portal. The RFC 8910 let the DHCP server
to send an API URI that indicates the presence of a captive portal, and
let the clients to detect the presence of a captive portal and the URL
that let them to authenticate.

However, I think that the RFC is not implemented yet. The RFC replaces
the RFC 7710 (which added a captivep-portal-url option) and the RFC
3679, which added a default-url option. The present RFC overwrites this
option, number 114.

I just added in my configuration the following options:

option default-url "https://example.com/api.json";;  # 114 from RFC3679
option v4-captive-portal "https://example.com/api.json";;  # 160 from
RFC7710

These are recognized by isc-dhcp-server. But when I launch the server
and add a client, I don't see any of the two options when I analyse the
DHCP packets (with tcpdump or Wireshark for example). Did I make
something wrong? Is there something unimplemented?

One more question: does someone know how clients react to this DHCP
option? Who really cares about this URL? When is the client informed
that there is a captive portal, and how is they redirected?

Regards,

-- 
Yohann D'Anello
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: 
<https://lists.isc.org/pipermail/dhcp-users/attachments/20220420/cf877759/attachment-0001.sig>

------------------------------

Message: 2
Date: Wed, 20 Apr 2022 10:57:14 -0400 (EDT)
From: perl-list <perl-l...@network1.net>
To: Users of ISC DHCP <dhcp-users@lists.isc.org>
Subject: Re: RFC 8910
Message-ID:
        <755643326.2179936.1650466634032.javamail.zim...@network1.net>
Content-Type: text/plain; charset=utf-8

The server will only send these options if the client asks for them.  In the 
discover or request packets from the client, have a look at option 55 
(parameter request list).  If that list does not contain option 114 or 160 then 
the server won't send them.  Even if the server did send them without being 
requested, the client would likely ignore them not knowing what to do with them.

----- Original Message -----
> From: "?n?rant" <yner...@crans.org>
> To: "Users of ISC DHCP" <dhcp-users@lists.isc.org>
> Sent: Wednesday, April 20, 2022 10:04:00 AM
> Subject: RFC 8910

> Hello!

> For my organization, I am using isc-dhcp-server as DHCP server.

> We want to deploy a captive portal for a new open Wifi to authenticate
> users. However, we want to do it great, and avoid to do Man-in-the-
> middle attacks to access the portal. The RFC 8910 let the DHCP server
> to send an API URI that indicates the presence of a captive portal, and
> let the clients to detect the presence of a captive portal and the URL
> that let them to authenticate.

> However, I think that the RFC is not implemented yet. The RFC replaces
> the RFC 7710 (which added a captivep-portal-url option) and the RFC
> 3679, which added a default-url option. The present RFC overwrites this
> option, number 114.

> I just added in my configuration the following options:

> option default-url "https://example.com/api.json";; # 114 from RFC3679
> option v4-captive-portal "https://example.com/api.json";; # 160 from
> RFC7710

> These are recognized by isc-dhcp-server. But when I launch the server
> and add a client, I don't see any of the two options when I analyse the
> DHCP packets (with tcpdump or Wireshark for example). Did I make
> something wrong? Is there something unimplemented?

> One more question: does someone know how clients react to this DHCP
> option? Who really cares about this URL? When is the client informed
> that there is a captive portal, and how is they redirected?

> Regards,

> --
> Yohann D'Anello

> --
> ISC funds the development of this software with paid support subscriptions.
> Contact us at https://www.isc.org/contact/ for more information.

> dhcp-users mailing list
> dhcp-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/dhcp-users


------------------------------

Message: 3
Date: Wed, 20 Apr 2022 17:26:57 +0200
From: ?n?rant <yner...@crans.org>
To: Users of ISC DHCP <dhcp-users@lists.isc.org>
Subject: Re: RFC 8910
Message-ID: <335068cc7782aef4a5d2417f0dabc2e439d2ecc7.ca...@crans.org>
Content-Type: text/plain; charset="utf-8"

Thank you. My requests didn't include the option 114 indeed. I tried to
ask it, and the server answers me correctly.

It is now time for me to see how clients deal with this information.

Thank you!

Regards,

-- 
Yohann D'Anello


Le mercredi 20 avril 2022 ? 10:57 -0400, perl-list a ?crit?:
> The server will only send these options if the client asks for them.?
> In the discover or request packets from the client, have a look at
> option 55 (parameter request list).? If that list does not contain
> option 114 or 160 then the server won't send them.? Even if the
> server did send them without being requested, the client would likely
> ignore them not knowing what to do with them.
> 
> ----- Original Message -----
> > From: "?n?rant" <yner...@crans.org>
> > To: "Users of ISC DHCP" <dhcp-users@lists.isc.org>
> > Sent: Wednesday, April 20, 2022 10:04:00 AM
> > Subject: RFC 8910
> 
> > Hello!
> 
> > For my organization, I am using isc-dhcp-server as DHCP server.
> 
> > We want to deploy a captive portal for a new open Wifi to
> > authenticate
> > users. However, we want to do it great, and avoid to do Man-in-the-
> > middle attacks to access the portal. The RFC 8910 let the DHCP
> > server
> > to send an API URI that indicates the presence of a captive portal,
> > and
> > let the clients to detect the presence of a captive portal and the
> > URL
> > that let them to authenticate.
> 
> > However, I think that the RFC is not implemented yet. The RFC
> > replaces
> > the RFC 7710 (which added a captivep-portal-url option) and the RFC
> > 3679, which added a default-url option. The present RFC overwrites
> > this
> > option, number 114.
> 
> > I just added in my configuration the following options:
> 
> > option default-url "https://example.com/api.json";; # 114 from
> > RFC3679
> > option v4-captive-portal "https://example.com/api.json";; # 160 from
> > RFC7710
> 
> > These are recognized by isc-dhcp-server. But when I launch the
> > server
> > and add a client, I don't see any of the two options when I analyse
> > the
> > DHCP packets (with tcpdump or Wireshark for example). Did I make
> > something wrong? Is there something unimplemented?
> 
> > One more question: does someone know how clients react to this DHCP
> > option? Who really cares about this URL? When is the client
> > informed
> > that there is a captive portal, and how is they redirected?
> 
> > Regards,
> 
> > --
> > Yohann D'Anello
> 
> > --
> > ISC funds the development of this software with paid support
> > subscriptions.
> > Contact us at https://www.isc.org/contact/?for more information.
> 
> > dhcp-users mailing list
> > dhcp-users@lists.isc.org
> > https://lists.isc.org/mailman/listinfo/dhcp-users

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: 
<https://lists.isc.org/pipermail/dhcp-users/attachments/20220420/489b2604/attachment-0001.sig>

------------------------------

Subject: Digest Footer

_______________________________________________
ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.

dhcp-users mailing list
dhcp-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/dhcp-users


------------------------------

End of dhcp-users Digest, Vol 162, Issue 8
******************************************

Reply via email to