Subject: Re: [mif] DNS selection with HE-MIF

From: Ted Lemon <[email-masked]>
Date: Fri, 1 Feb 2013 20:11:26 +0000

On Jan 31, 2013, at 1:56 AM, GangChen <[email-masked]> wrote:
> Therefore, RFC6731 should be recommended as the proper solution for
> DNS selections.

RFC6731 is only applicable in a very restricted set of use cases, and cannot be counted upon to resolve this issue in the majority of use cases.   I would expect it to be helpful in the case of some enterprise situations (but not with BYOD) and with some mobile handsets (but only for the mobile provider's private domains).   So we simply can't use this to address the problem.

---

From: GangChen <[email-masked]>
Date: Sun, 3 Feb 2013 22:12:30 +0800

2013/2/2, Ted Lemon <[email-masked]>:
> RFC6731 is only applicable in a very restricted set of use cases, and cannot
> be counted upon to resolve this issue in the majority of use cases.  I

Acknowledged. RFC6731 listed the use cases. The described case 1, 2 in
the previous message can be likely solved through RFC6731. So the
statement of applicability is particularly for those cases.

> would expect it to be helpful in the case of some enterprise situations (but
> not with BYOD) and with some mobile handsets (but only for the mobile
> provider's private domains).   So we simply can't use this to address the
> problem.

I would like to learn more about the problems. One description I found
was documented in http://tools.ietf.org/html/rfc6418#section-4.1. If I
understand correctly, it mainly talk about the issues of coordination
with private name space among different interfaces. I guess those
issues are also the targets of RFC6731. If there is anything missing,
it would be helpful you could kindly point out.

Best Regards

Gang

---

From: Ted Lemon <[email-masked]>
Date: Sun, 3 Feb 2013 15:04:36 +0000

On Feb 3, 2013, at 9:12 AM, GangChen <[email-masked]> wrote:
> I would like to learn more about the problems.

There are quite a few separate issues.   We generally treat DNS results as if they are essentially stateless—regardless of who asks the question, they should get the same answer.   However, there are a lot of situations where this simply isn't true.   Some of them are covered by RFC6731, but most are not.

The most obvious cases are situations where there is in fact a split dns architecture, but RFC6731 isn't applicable.   This is probably most split dns situations.

The second set of cases are cases where DNS is used to operate a captive portal.   In these cases, the DNS server on the captive portal will give different answers than a DNS server on a working 3G link, for instance.   So if HE treats DNS responses as if they were generally equivalent, either we will be unable to ever see the captive portal web page, or we will be unable to use the 3G network without logging in to the captive portal.   Neither situation is desirable.

A third, less obvious, set of cases are where DNS is used to optimize CDN delivery.   In this case, suppose I have a 3G interface that doesn't have CDN-optimized DNS, and a connection through my ISP on the wireless LAN that does have CDN-optimized DNS.   In this situation, if I treat the two DNS servers as equivalent, then I may use the 3G DNS server to look up information I will then use to connect to the CDN over the wireless LAN interface.   This will likely result in suboptimal routing, and unacceptable performance.

This is why when I've discussed this issue in the past, I've always argued that each provisioning domain needs to be treated separately.   We should not look up names in one provisioning domain and use them in another; if we want to try connecting across multiple provisioning domains, we should do DNS lookups on each such provisioning domain, and use the results we get only for connecting within that provisioning domain.

---

From: Keith Moore <[email-masked]>
Date: Sun, 03 Feb 2013 10:46:47 -0500

> This is why when I've discussed this issue in the past, I've always argued that each provisioning domain needs to be treated separately.   We should not look up names in one provisioning domain and…
Problem is, this is bad for the Internet architecture, as it basically 
encourages using DNS as a routing protocol.

Keith

---

From: Ted Lemon <[email-masked]>
Date: Sun, 3 Feb 2013 16:05:54 +0000

On Feb 3, 2013, at 10:46 AM, Keith Moore <[email-masked]> wrote:
> Problem is, this is bad for the Internet architecture, as it basically encourages using DNS as a routing protocol.

I think using DNS for CDNs is a bad idea, and it's also something that I think people are moving away from, but it is an issue, so I described it.   All of the use cases I described are essentially abuses of the DNS; the question is whether we will spec out something that is robust in the face of these abuses, or whether we will spec out something that simply falls over and dies when people abuse the DNS.

In my mind, these scenarios are essentially DoS attack scenarios: the end user is being attacked by the DNS provider in a provisioning domain, who is giving them corrupt data that will negatively impact their use of the network.   The question is, do we allow that attack to spill over into other provisioning domains, or do we spec out a standard that prevents such spill-over?

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 03 Feb 2013 16:32:14 +0000

On 03/02/2013 15:46, Keith Moore wrote:
>> This is why when I've discussed this issue in the past, I've always
>> argued that each provisioning domain needs to be treated separately.  
>> We should not look up names in one provisioning domain and use them in
>> another; if we want to try connecting across multiple provisioning
>> domains, we should do DNS lookups on each such provisioning domain,
>> and use the results we get only for connecting within that
>> provisioning domain.

It also means that the resolver performing the lookup needs to
understand this concept of "provisioning domain" and to know which
such domain(s) matter for the lookup in question.

My big book of Internet magic doesn't seem to explain how the
resolver would know this, or how the RR would be tagged to
designate which domain(s) it applies to.

    Brian

---

From: Ted Lemon <[email-masked]>
Date: Sun, 3 Feb 2013 16:35:12 +0000

> designate which domain(s) it applies to.

Right, this is why this working group exists (IMHO).

---

From: Keith Moore <[email-masked]>
Date: Sun, 03 Feb 2013 11:36:05 -0500

On 02/03/2013 11:05 AM, Ted Lemon wrote:
> I think using DNS for CDNs is a bad idea, and it's also something that I think people are moving away from, but it is an issue, so I described it.   All of the use cases I described are essentially abuses of the DNS;
agree.
> the question is whether we will spec out something that is robust in the face of these abuses, or whether we will spec out something that simply falls over and dies when people abuse the DNS.
I think this is a case where IETF has failed (over a long period of 
time) to devote sufficient attention to managing the Internet architecture.

In this case, IETF has failed to recognize the cases where people were 
tempted to abuse DNS, and to either adapt DNS or provide alternative 
solutions.   There was little about the Internet architecture, and 
nothing about DNS, that was incompatible with having multiple network 
interfaces on a host.  It's only when DNS is abused that this problem 
crops up.

And now IETF has essentially asked a working group with a very narrow 
scope to fix a fairly broad architectural issue that has been 
exacerbated by 15 or so years of neglect.  Of course, IETF does this all 
the time - MIF isn't the only group that's been asked to patch 
deficiencies in the architecture that were really beyond its proper 
scope.  But this particular issue seems thornier, and to have worse 
long-term consequences, than most.

This is in some sense a structural problem with IETF - its division of 
work into areas based loosely on layers of the protocol stack, and its 
habit of trying to do everything in narrowly-scoped working groups, 
almost entirely precludes resolution of architectural issues, 
particularly when those issues involve conflicts (and require 
compromises) between different layers and/or different interests.

But my point isn't to make a speech.  My point is to say that any real 
solution to this problem is probably beyond a reasonable scope of the 
MIF WG.   Though perhaps MIF could propose a solution as a starting 
point, it should not be trying to define the solution.  It doesn't, and 
cannot, represent a wide enough set of interests to dictate the changes 
that need to occur to DNS and DNS configurations and/or ICMP and/or 
network configurations and/or applications and/or network stacks, to 
resolve this satisfactorily.
> In my mind, these scenarios are essentially DoS attack scenarios: the end user is being attacked by the DNS provider in a provisioning domain, who is giving them corrupt data that will negatively i…

Or maybe the thing to do is document the problems, and explain why 
they're architectural issues, and perhaps suggest that IAB and/or IESG 
should undertake to bring a broad set of interests to the table to 
resolve such issues.

Keith

---

From: Keith Moore <[email-masked]>
Date: Sun, 03 Feb 2013 11:37:26 -0500

> Right, this is why this working group exists (IMHO).
And IMO, it's far beyond a reasonable scope for this, or any, WG that is 
limited to a single area.  And perhaps a traditional IETF WG isn't the 
right structure for tackling this kind of problem.

Keith

---

From: Ted Lemon <[email-masked]>
Date: Sun, 3 Feb 2013 16:48:31 +0000

On Feb 3, 2013, at 11:37 AM, Keith Moore <[email-masked]> wrote:
> And IMO, it's far beyond a reasonable scope for this, or any, WG that is limited to a single area.  And perhaps a traditional IETF WG isn't the right structure for tackling this kind of problem.

This seems like a fairly nonsensical statement.   The IETF has areas, and working groups.   It is frequently the case that work being done in a working group affects more than one area.   The IETF has not burst into an explosion of pure energy as a result of the streams being crossed thus far.   I suspect we are safe in the future as well.

If you have some concrete proposal to make, I think it would be worth hearing it, but if you are just going to take pot shots, there's not much the rest of us can do except to try to continue getting work done while ducking your occasional volley.

---

From: Keith Moore <[email-masked]>
Date: Sun, 03 Feb 2013 12:12:44 -0500

> This seems like a fairly nonsensical statement.   The IETF has areas, and working groups.   It is frequently the case that work being done in a working group affects more than one area.   The IETF…
My view is that the Internet (with IETF's help) has been painting itself 
into increasingly smaller corners for at least 15 years now, maybe 
longer.   NATs, DNS hacks, interception proxies, various kinds of packet 
filters, all basically make the Internet less predictable for 
applications, and thus increase development, operation, and support 
costs for everybody.  Trying to work around them all just makes the 
Internet more complex without making it more functional.

The IETF needs to get out of the habit of treating every problem as 
something that can be solved by spinning up a narrowly-focused working 
group, that functions just like every other working group because 
"that's the way we do things".

I realize, of course, that MIF can't change IETF's habits.   But if 
you're looking for a sane way forward, it's essential to realize that 
IETF's habits are a huge part of the problem.  Otherwise you keep trying 
to use the same working habits to address problems that they 
fundamentally cannot address.

> If you have some concrete proposal to make, I think it would be worth hearing it, but if you are just going to take pot shots, there's not much the rest of us can do except to try to continue getti…

My proposal is to document the problems as best you can, and make 
concrete suggestions for areas in which the Internet architecture might 
be tweaked, but don't try to resolve the conflicts within MIF.   
Instead, ask IAB to look at the matter and provide IESG with advice as 
to how to proceed.

Keith

---

From: Ted Lemon <[email-masked]>
Date: Sun, 3 Feb 2013 18:54:24 +0000

On Feb 3, 2013, at 12:12 PM, Keith Moore <[email-masked]> wrote:
> My proposal is to document the problems as best you can, and make concrete suggestions for areas in which the Internet architecture might be tweaked, but don't try to resolve the conflicts within MIF.   Instead, ask IAB to look at the matter and provide IESG with advice as to how to proceed.

This isn't bad advice.   It's worth noting that at least one member of the IAB has in fact been participating in the discussion already, however, so it's been my ongoing assumption that this issue is already on their radar, and that if we were doing the wrong thing, we would have heard something about it already.   I say that not to express resistance to your proposal, but simply to observe that I don't think we are _quite_ as far off the rails as you are suggesting.

---

From: Michael Richardson <[email-masked]>
Date: Sun, 03 Feb 2013 15:09:58 -0500

>>>>> "Ted" == Ted Lemon <[email-masked]> writes:
    Ted> The second set of cases are cases where 

"where DNS is incorrectly used" 

    Ted> to operate a captive portal.  

The IETF needs to write a BCP on captive portals. Abusing DNS is never
the right answer due to DNSSEC, the MIF situation just makes that
obvious to more users.

-- 
Michael Richardson <[email-masked]>, Sandelman Software Works

---

From: Ted Lemon <[email-masked]>
Date: Mon, 4 Feb 2013 04:03:36 +0000

> the right answer due to DNSSEC, the MIF situation just makes that

It would be nice if we had a solution to offer, and not just a set of practices to follow.   Right now there is no IETF protocol that can be used to say "you have connected to a captive portal, please do BLAH so that you can access the network."

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 04 Feb 2013 08:09:02 +0000

> This isn't bad advice.   It's worth noting that at least one member of the IAB has in fact been participating in the discussion already, however, so it's been my ongoing assumption that this issue…

Although it isn't about this precise problem, I have been banging on
about referrals for several years now (the most recent attempt being at
http://tools.ietf.org/html/draft-carpenter-referral-ps-02).

I mention this because despite a BOF at IETF76 and at least two IAB members
having showed interest in the problem, no traction has been gained whatever.
I think there's a strong temptation to put this whole topic on the "too hard"
heap, so we (collectively) continue to fiddle with the edges of it,
e.g. expecting DNS server selection to solve the problem.

   Brian

---

From: GangChen <[email-masked]>
Date: Mon, 4 Feb 2013 18:44:56 +0800

2013/2/3, Ted Lemon <[email-masked]>:
> There are quite a few separate issues.   We generally treat DNS results as
> if they are essentially stateless—regardless of who asks the question, they
> should get the same answer.   However, there are a lot of situations where
> this simply isn't true.   Some of them are covered by RFC6731, but most are
> not.
>
> The most obvious cases are situations where there is in fact a split dns
> architecture, but RFC6731 isn't applicable.   This is probably most split
> dns situations.

I suppose you indicate the issue which is probably described in
http://tools.ietf.org/html/rfc6731#section-2.3. RFC6731 claimed that
"these problems might be solvable ONLY by manual user intervention.

> The second set of cases are cases where DNS is used to operate a captive
> portal.   In these cases, the DNS server on the captive portal will give
> different answers than a DNS server on a working 3G link, for instance.   So

The second set of cases seems a variant of a split dns. A captive
portal is represented by RR with masquerading IP. That make different
answers returned with same FQDN.

> if HE treats DNS responses as if they were generally equivalent, either we
> will be unable to ever see the captive portal web page, or we will be unable
> to use the 3G network without logging in to the captive portal.   Neither
> situation is desirable.

will add the case into the description of failed support in HE-MIF draft

> A third, less obvious, set of cases are where DNS is used to optimize CDN
> delivery.   In this case, suppose I have a 3G interface that doesn't have
> CDN-optimized DNS, and a connection through my ISP on the wireless LAN that
> does have CDN-optimized DNS.   In this situation, if I treat the two DNS
> servers as equivalent, then I may use the 3G DNS server to look up
> information I will then use to connect to the CDN over the wireless LAN
> interface.   This will likely result in suboptimal routing, and unacceptable
> performance.

If there is no configuration from 6731, HE-MIF would send DNS request
on both interface in parallel. The node may generate a list to
indicate remote peers. HE will help to pick fast interface. I guess it
may rectify the unexpected suboptimal routing in some extents. But I
think HE-MIF is not intended to resolve DNS selection issue initially.

> This is why when I've discussed this issue in the past, I've always argued
> that each provisioning domain needs to be treated separately.   We should
> not look up names in one provisioning domain and use them in another; if we
> want to try connecting across multiple provisioning domains, we should do
> DNS lookups on each such provisioning domain, and use the results we get
> only for connecting within that provisioning domain.

The problems are caused since DNS answers may not be kept with
information of the provisioning domain from which the answer comes.
HE-MIF may alleviate the issues with failover ability as best as it
can. Backing to the target of this thread, we intent to describe
issues within HE-MIF context. For issues in general and concrete
recommendations, would it make sense to draft new I-D?

Best Regards

Gang

---

From: Ted Lemon <[email-masked]>
Date: Mon, 4 Feb 2013 13:56:32 +0000

On Feb 4, 2013, at 5:44 AM, GangChen <[email-masked]> wrote:
> Backing to the target of this thread, we intent to describe

No.   The point of HE-MIF is to solve the problem.   So not talking about the full problem in the HE-MIF solution means that we're producing something that's probably harmful.

It sounds like you think there's some value to doing DNS queries within one provisioning domain, and then using the results in the other provisioning domain.   Can you explain why?

---

From: GangChen <[email-masked]>
Date: Tue, 5 Feb 2013 12:02:06 +0800

2013/2/4, Ted Lemon <[email-masked]>:
> No.   The point of HE-MIF is to solve the problem.   So not talking about
> the full problem in the HE-MIF solution means that we're producing something
> that's probably harmful.

Allow me to explore *the problem* a bit. Following the discussion, I
realize there are actually two seperated problems.
1) Using HE-MIF (no domain information provisioned) to select DNS
2) Once domain name is resolved, using answer only within the
provisioning domain

For 1),

If there is no domain information provisioned (e.g. RFC6731),HE-MIF
selects DNS server using *connection speed* other than provisioning
domain information. I guess it desirable to do DNS query within a
matched provisioning domain. So pre-provisioned domain
information(e.g. RFC6731) would prioritize the interface sending DNS
query.

# For 2),#

I can't comment on benefits of "doing DNS queries within one
provisioning domain, and then using the results in the other
provisioning domain." But HE-MIF has to do in some cases, because that
maybe a normal node behavior, like stated in RFC6418 "A node usually
has a node-scoped routing table". This issue may retrospect to basic
Internet host design in RFC1122. Changing the model would go beyond
HE-MIF scope.

We would surely document full problem in HE-MIF solution at next update.

>
> It sounds like you think there's some value to doing DNS queries within one
> provisioning domain, and then using the results in the other provisioning
> domain.   Can you explain why?

See above # For 2),#

Best Regards

Gang

---

From: Ted Lemon <[email-masked]>
Date: Tue, 5 Feb 2013 05:35:18 +0000

> Internet host design in RFC1122. Changing the model would go beyond

Okay, so your point is that we can't do connections within a provisioning domain, because we don't have control over how a connection is routed.

I agree that this is a problem, but it is explicitly within the scope of the MIF charter to consider this problem and document it.   It is quite likely the case that solving the problem is outside of the current MIF charter, and that such work, if attempted, ought not to occur in MIF.

However, if in fact the HE-MIF document can't work correctly without solving this problem, then it is certainly within the scope of the current charter for the MIF working group to draw that conclusion.

For my part, what I am saying is that HE-MIF can't really be very useful without solving this problem.   It is not in fact the case that a MIF node can have a single node-scoped routing table and still succeed in communicating on the network in the face of, for example, an interface that's connected to a captive portal but providing a default route, as such captive portals typically do.

---

From: GangChen <[email-masked]>
Date: Tue, 5 Feb 2013 18:47:10 +0800

2013/2/5, Ted Lemon <[email-masked]>:
> Okay, so your point is that we can't do connections within a provisioning
> domain, because we don't have control over how a connection is routed.
>
> I agree that this is a problem, but it is explicitly within the scope of the
> MIF charter to consider this problem and document it.   It is quite likely
> the case that solving the problem is outside of the current MIF charter, and
> that such work, if attempted, ought not to occur in MIF.
>
> However, if in fact the HE-MIF document can't work correctly without solving
> this problem, then it is certainly within the scope of the current charter
> for the MIF working group to draw that conclusion.
>
> For my part, what I am saying is that HE-MIF can't really be very useful
> without solving this problem.   It is not in fact the case that a MIF node
> can have a single node-scoped routing table and still succeed in
> communicating on the network in the face of, for example, an interface
> that's connected to a captive portal but providing a default route, as such
> captive portals typically do.

May I raise two points.

1) Interface selection is not only goal of HE-MIF. Essentially, HE-MIF
will make MIF node with automatic fallback ability.

On the interface selection stage, HE-MIF is actually hand the power to
RFC4191, 6731, I-D.ietf-mif-dhcpv6-route-option, etc.
If there is a failure or no such provisioning information, HE-MIF will
take over by sending the probing message on all potential interfaces.

2) I guess the problem is happened when the host is implemented with a
weak model.

The problem occurred when a interface in provisioning domain A to
reach a peer that is answered by DNS server in provisioning domain B

Since it's a single node-scoped routing table, there maybe a failed
case when an interface in provisioning domain A using parameters of
provisioning domain B(e.g. default gw) to make probing. The probe
likely would fail. Ideally, HE-MIF could choose the right interface
matching the provisioning domain. However, if the interface in
provisioning domain A using default gw could reach the peer, it will
have a problem. I believe the problem is similar with
http://tools.ietf.org/html/rfc6731#section-2.3. The only solution is
manual user intervention as far as I can say.

Best Regards

Gang

---

From: Ted Lemon <[email-masked]>
Date: Tue, 5 Feb 2013 14:22:59 +0000

On Feb 5, 2013, at 5:47 AM, GangChen <[email-masked]> wrote:
> Ideally, HE-MIF could choose the right interface

No, this is not true.   Furthermore, this failure mode happens to me on a regular basis when my handset connects to a Wifi SSID it recognizes; everything IP-dependent stops until I either disable WiFi or authenticate to the captive portal.  This is a trivially easy attack to do on handsets with WiFi (which is most handsets nowadays).

Similarly, some web gateways, particularly in airports and hotels, only offer service on ports 80 and 443.  I'd like to be able to use this transport where it works, because it's cheaper than my 4G LTE service (at least hypothetically).   But a solution that follows the weak host model will not succeed in this situation—it will either always use LTE, or always use the WiFi.

If HE-MIF does not address this use case, it seems to me that we simply aren't addressing the bulk of the use cases that motivated the formation of this working group.   If that's the case, why do the work?

---

From: GangChen <[email-masked]>
Date: Wed, 6 Feb 2013 15:29:06 +0800

2013/2/5, Ted Lemon <[email-masked]>:
> No, this is not true.   Furthermore, this failure mode happens to me on a
> regular basis when my handset connects to a Wifi SSID it recognizes;
> everything IP-dependent stops until I either disable WiFi or authenticate to
> the captive portal.  This is a trivially easy attack to do on handsets with
> WiFi (which is most handsets nowadays).
>
> Similarly, some web gateways, particularly in airports and hotels, only
> offer service on ports 80 and 443.  I'd like to be able to use this
> transport where it works, because it's cheaper than my 4G LTE service (at
> least hypothetically).   But a solution that follows the weak host model
> will not succeed in this situation—it will either always use LTE, or always
> use the WiFi.
>
> If HE-MIF does not address this use case, it seems to me that we simply
> aren't addressing the bulk of the use cases that motivated the formation of
> this working group.   If that's the case, why do the work?

I guess the information on this link may relieve your concerns.
http://www.ietf.org/mail-archive/web/mif/current/msg01138.html

I have tested hotspots in our network. The captive portal systems do
not reply with their own IP address, but reply with the IP
address of the queried FQDN, and then do IP masquerading  as the
destination IP address. It's using HTTP redirection to the captive portal.

In this way, HE-MIF would work well.
Since TCP handshake would be broken if there is a captive portal,
HE-MIF node would fallback to other interfaces automatically.

Best Regards

Gang

---

From: Ted Lemon <[email-masked]>
Date: Thu, 7 Feb 2013 02:14:58 +0000

> http://www.ietf.org/mail-archive/web/mif/current/msg01138.html

I am not looking to be reassured.   I would like the proposal to address the real and serious issues I have raised.   You are of course free to say "no, we do not intend to address these concerns."

---

From: GangChen <[email-masked]>
Date: Thu, 7 Feb 2013 10:50:23 +0800

Hello Ted,

2013/2/7, Ted Lemon <[email-masked]>:
> I am not looking to be reassured.   I would like the proposal to address the
> real and serious issues I have raised.   You are of course free to say "no,
> we do not intend to address these concerns."

Your concern has been understood well.
It would be seriously considered at next update.
Hopefully, we could come up with a thoughtful solution after checking
with other co-authors.
If there is a proposal in your mind, that is highly appreciated.

Best Regards

Gang