Subject: [mif] AD review of draft-ietf-mif-current-practices

From: Jari Arkko <[email-masked]>
Date: Mon, 28 Mar 2011 15:51:41 +0200

I have re-reviewed this draft after changes per my earlier review. I 
think the draft is ready to move forward with one change: please add a 
reference to RFC 5113 in Section 3.3 and explain that it contains 
further discussion about the access network selection problem.

I don't have a strong opinion on whether we should add something to 
highlight Ted's scenario from today's meeting. I'll let the working 
group and the chairs decide that. I have set the status of the draft to 
Revised ID Needed, and we are ready to start IETF Last Call as soon as 
the above issue is fixed; if you don't add anything about the other 
scenario then a quick update this week would move the draft forward. Let 
me know when you have a new version that can be advanced.

Jari

---

From: Ted Lemon <[email-masked]>
Date: Mon, 28 Mar 2011 15:24:45 +0000

FYI, this is a rough approximation of the text I would want to add:

4.1a.  DNS resolution issues with captive portals

   A MIF node (M1) has an active interface(I1) connected to a network
   (N1) which has its DNS server (S1) and another active interface
   (I2) connected to a network (N2) which has its DNS server (S2).  S1
   is configured to respond to any A or AAAA record query with the
   IP address of a captive portal, so as to redirect web browsers to an
   access control portal web page.  Any of the following situations
   may occur:

   1.  M1 stack, based on its routing table, uses I2 to reach S1 to
       resolve "a.example.com".  M1 never reaches S1.  The name
       is not resolved.
   2.  M1 keeps only one set of DNS server addresses from the received
       configuration objects and kept S2 address.  M1 sends the
       forward DNS query for a.example.com to S2.  S2 responds with the
       correct answer, R1.   M1 attempts to contact R1 by way of I1.
       The connection fails.     Or, the connection succeeds,
       bypassing the security policy on N1, possibly exposing the
       owner of M1 to prosecution.
   3.  M1 keeps only one set of DNS server addresses from the received
       configuration objects and kept S1 address.  M1 sends the DNS
       query for a.example.com to S1.  S1 provides the address of its
       captive portal.   S1 attempts to contact this IP address using
       I1.   The application tries to connect to the wrong destination
       node, resulting in lack of service and possible security issues.
   4.  M1 has resolved an FQDN to the IP address of the captive portal
       connected to N1.  If the node loses connection to N1, the node
       may try to connect, via N2, to the same IP address as earlier,
       but as the address was only locally valid, connection setup
       fails.

---

From: <[email-masked]>
Date: Mon, 28 Mar 2011 15:47:18 +0000

Ted,

Good text. I agree the problem exist. The DNS server selection points to this issue as well:
--
(DISCUSS:
   What about those DNS servers that instead of negative answer always
   return positive reply with an IP address of some captive portal?)
--

IMHO the problem section should say that this problem (usually/always) disappears right after M1 has authenticated to the captive portal and interface becomes truly "up". I.e. human intervention is required to clear the situation, but once cleared, things work as they should - until captive portal possibly wants to renew authentication..

This problem btw means the M1 cannot start validating responses until authentication with captive portal shas been completed. 

Best regards,

	Teemu

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> ext Ted Lemon
> Sent: 28. maaliskuuta 2011 17:25
> To: Jari Arkko
> Cc: [email-masked]; mif
> Subject: Re: [mif] AD review of draft-ietf-mif-current-practices
> 
> _______________________________________________
> mif mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mif

---

From: <[email-masked]>
Date: Mon, 28 Mar 2011 18:11:04 +0200

Current practices draft is updated with reference to RFC5113. New version is: http://datatracker.ietf.org/doc/draft-ietf-mif-current-practices 

Pierrick

> -----Message d'origine-----
> De : [email-masked] [mailto:[email-masked]] De la part de Jari
> Arkko
> Envoyé : lundi 28 mars 2011 15:52
> À : [email-masked]; mif; Ted Lemon
> Objet : [mif] AD review of draft-ietf-mif-current-practices
>

---

From: Ted Lemon <[email-masked]>
Date: Mon, 28 Mar 2011 16:15:00 +0000

> FYI, this is a rough approximation of the text I would want to add:

I don't know if it's old age, stupidity or jet lag, but in case it wasn't clear, the document I was talking about here was the problem statement document, not the current practices document.  Sorry for replying on the wrong thread.

---

From: <[email-masked]>
Date: Wed, 30 Mar 2011 23:51:19 +0200

Any other comments with regards to this text? Is there an agreement to include it into the PS?

> De : [email-masked] [mailto:[email-masked]]
> Envoyé : lundi 28 mars 2011 17:47
> À : [email-masked]; [email-masked]
> Cc : [email-masked]; [email-masked]
> Objet : RE: AD review of draft-ietf-mif-current-practices
> 
> Ted,
> 
> IMHO the problem section should say that this problem (usually/always)
> disappears right after M1 has authenticated to the captive portal and
> interface becomes truly "up". I.e. human intervention is required to clear
> the situation, but once cleared, things work as they should - until
> captive portal possibly wants to renew authentication..
> 
> This problem btw means the M1 cannot start validating responses until
> authentication with captive portal shas been completed.
> 
> Best regards,
> 
> 	Teemu
> 
>