Subject: [mif] [Editorial Errata Reported] RFC6418 (3057)

From: RFC Errata System <[email-masked]>
Date: Wed, 21 Dec 2011 16:05:27 -0800 (PST)

The following errata report has been submitted for RFC6418,
"Multiple Interfaces and Provisioning Domains Problem Statement".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=6418&eid=3057

--------------------------------------
Type: Editorial
Reported by: Zhou Sujing <[email-masked]>

Section: 4.4

Original Text
-------------
For instance, the network may perform HTTP redirection or modify DNS behavior (Section 4.1) until the user has not authenticated.

Corrected Text
--------------
For instance, the network may perform HTTP redirection or modify DNS behavior (Section 4.1) until the user has been authenticated.

Notes
-----

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC6418 (draft-ietf-mif-problem-statement-15)
--------------------------------------
Title               : Multiple Interfaces and Provisioning Domains Problem Statement
Publication Date    : November 2011
Author(s)           : M. Blanchet, P. Seite
Category            : INFORMATIONAL
Source              : Multiple Interfaces
Area                : Internet
Stream              : IETF
Verifying Party     : IESG

---

From: Margaret Wasserman <[email-masked]>
Date: Wed, 21 Dec 2011 19:13:37 -0500

This erratum looks right to me.  I think we should accept it.

Margaret

---

From: Ted Lemon <[email-masked]>
Date: Thu, 22 Dec 2011 00:23:05 +0000

On Dec 21, 2011, at 7:13 PM, Margaret Wasserman wrote:
For instance, the network may perform HTTP redirection or modify DNS behavior (Section 4.1) until the user has not authenticated.

Corrected Text
--------------

Isn't this talking about captive portals?   If so, then *after* authentication you get unmodified DNS and HTTP; before authentication, you get forged DNS responses that force you to the captive portal.

---

From: <[email-masked]>
Date: Thu, 22 Dec 2011 10:24:24 +0100

I agree.

Pierrick

> -----Message d'origine-----
> De : Margaret Wasserman [mailto:[email-masked]]
> Envoyé : jeudi 22 décembre 2011 01:14
> À : RFC Errata System
> Cc : [email-masked]; SEITE Pierrick RD-RESA-REN;
> [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Objet : Re: [Editorial Errata Reported] RFC6418 (3057)
> 
> 
> > For instance, the network may perform HTTP redirection or modify DNS
> behavior (Section 4.1) until the user has not authenticated.
> >
> >
> >
> > Corrected Text
> > --------------
> > For instance, the network may perform HTTP redirection or modify DNS
> behavior (Section 4.1) until the user has been authenticated.
> >
> >
> > Notes
> > -----
> >
> >
> > Instructions:
> > -------------

---

From: Simon Perreault <[email-masked]>
Date: Thu, 22 Dec 2011 09:05:27 -0500

On 2011-12-21 19:23, Ted Lemon wrote:
> Isn't this talking about captive portals? If so, then *after* authentication you
> get unmodified DNS and HTTP; before authentication, you get forged DNS responses
> that force you to the captive portal.

Just for the sake of discussion...

Captive portals that modify DNS responses are exceedingly rare. Usually, captive 
portals work by NATing the destination address of packets emitted from clients 
having an unauthenticated link-layer addresses. The reason, I presume, is that 
DNS responses get cached by the OS and/or application, so sending "wrong" DNS 
responses to clients just doesn't work well.

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: <[email-masked]>
Date: Thu, 22 Dec 2011 15:10:34 +0100

> De : [email-masked] [mailto:[email-masked]] De la part de
> Simon Perreault
> Envoyé : jeudi 22 décembre 2011 15:05
> À : Ted Lemon
> Cc : <[email-masked]>; <[email-masked]>
> Objet : Re: [mif] [Editorial Errata Reported] RFC6418 (3057)
> 
> having an unauthenticated link-layer addresses. 

I'm not an expert in captive portals but I think NAT based solution is as rare as DNS based :-) Captive portal are usually based on HTTP redirection.

Pierrick

The reason, I presume,
> is that
> _______________________________________________
> mif mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mif

---

From: Marc Blanchet <[email-masked]>
Date: Thu, 22 Dec 2011 09:18:31 -0500

> I'm not an expert in captive portals but I think NAT based solution is as rare as DNS based :-) Captive portal are usually based on HTTP redirection.

that is also my understanding: HTTP redirection is widely used.

Marc.

---

From: Simon Perreault <[email-masked]>
Date: Thu, 22 Dec 2011 09:42:41 -0500

> that is also my understanding: HTTP redirection is widely used.

NAT is not "rare", at least at the places I go I see it quite often, but you're 
right that HTTP redirection is very common, probably more than NAT.

Simon