Subject: [mif] about draft-blanchet-mif-problem-statement-00.txt

From: marcelo bagnulo braun <[email-masked]>
Date: Sun, 15 Mar 2009 18:41:27 +0100

Hi,

Interesting draft, thanks for writing this up

Some comments and questions below

2.  Split DNS

   A multi-homed host may have one of its interfaces facing a DNS
   service which resolves private names and addresses, as stated in
   [I-D.savolainen-6man-fqdn-based-if-selection].  This split DNS may
   occur when a VPN connection to an enterprise network is setup or in a
   service provider's network for subscribers-only services.  These
   private names and addresses are only relevant to a specific
   interface.  Therefore the traffic related to these names and
   addresses has to go through the right interface.  However, a typical
   IP stack does not maintain a binding of the origin of the DNS name
   resolution with its routing table.  Therefore the trafic might go to
   the wrong interface and never reach the destination.

I think it would be good to describe the problem a bit more in depth.
I mean, a multihomed device may learn multiple DNS servers using dhcp. 
One of them can be the private part of a split DNS server.
Now, the first question, i guess, is if a multihomed host has two DNS 
servers which provide different information, which one it should query?
Next, once it has decided which one it will query, it may need to use 
the right interface in order to reahc the selected DNS server
Then, once it gets the answer back, it will need to use the same 
interface to make sure it works

does this makes sense? If so, i think it would be good to describe it in 
more detail in the description of the problem

3.  Routing

   A multi-homed host may have multiple routes to a destination.
   However, by default, it does not have any hint concerning which
   interface would be the best to use for that destination.  For
   example, as discussed in
   [I-D.savolainen-6man-fqdn-based-if-selection] and
   [I-D.hui-ip-multiple-connections-ps], a service provider might want
   to influence the routing table of the host connecting to its network.
   (TBD: expand)

I haven't read the other docs yet, but at this point, this is not clear 
to me
I mean, i understnad that a provider would want to influence the routing 
table of its hosts, but would the owner of the host want that as well?
what about more specific routes in RADV? why this is not enough?
Are you considering IPv4 and/or IPv6?

   A host usually has a node-scoped routing table.  Therefore, when a
   multi-homed host is connected to multiple networks and each service
   provider wants to influence the routing table of the host, then
   conflicts might arise from the multiple routing information being
   pushed to the host.

I fail to understand this.... an example would be great

   A user on such multi-homed host might want a local policy to
   influence which interface will be used based on various conditions.

An example about this would be also help understanding the situation
I mean, from the disucssion on the charter item, it seemed that what was 
being considered here is sending one flow per one interface while a 
different application through another one. This is not obvious at all 
from this description

   On a multi-homed host, some source addresses are not valid if used on
   some interfaces.  For example, an RFC1918 source address might be
   appropriate on the VPN interface but not on the public interface of
   the multi-homed host.  If the source address is not chosen
   appropriately, then sent packets might be filtered in the path if
   source address filtering is in place and reply packets might never
   come back to the source.

Right, this is very clear. But how is this related to the routing table?
I mean, wouldn't this a completelly different section about source 
address selection? (like the next section for instance)

4.  Address Selection Policy

   An address selection policy [RFC3484] is used to choose the right
   source and destination address for a new connection.  It is
   implemented globally in the node IP stack.

Are you talking only about hosts implementing rfc3484?
IPv4 only hosts are out of the scope of the problem?

---

From: <[email-masked]>
Date: Sun, 15 Mar 2009 20:54:23 +0100

Marcelo,

>Now, the first question, i guess, is if a multihomed host has 
>two DNS servers which provide different information, which one 
>it should query?
>Next, once it has decided which one it will query, it may need 
>to use the right interface in order to reahc the selected DNS 
>server Then, once it gets the answer back, it will need to use 
>the same interface to make sure it works
>
>does this makes sense? If so, i think it would be good to 
>describe it in more detail in the description of the problem

It does make sense. Have you checked draft-savolainen-mif-dns-server-selection, which is exactly about this?

In there I propose a host to use DNS suffixes of FQDN to be resolved for determining which interface's DNS servers to use for a DNS query (i.e. look for interface that is known to have the matching suffix). A host can also query (in parallel or in serial) through DNS servers of different interfaces, but in that case it must not stop asking when receiving negative response, as it may be that a DNS server of another interface is able to reply positively.

When host gets an answer back, it should use source/destination address selection algorithms in proper way - I comment on this also on the draft. When I originally proposed host would use the DNS suffix also for interface selection, there was negative comments that DNS should not be involved in routing decisions. Thus the current draft focuses on selecting right DNS server per FQDN, after FQDN has been resolved to an IP address, it is for source/destination address selection algorithm to continue from there - which may not be trivial. Especially on IPv4 this may be difficult, if e.g. public Internet facing interface is using RFC1918 private addresses, and private Intranet facing interface is using the same RFC1918 addresses. 

Best regards,

	Teemu

---

From: Lars Eggert <[email-masked]>
Date: Tue, 17 Mar 2009 11:30:54 -0700

Hi,

On 2009-3-15, at 12:54, Savolainen Teemu (Nokia-D-MSW/Tampere) wrote:
> In there I propose a host to use DNS suffixes of FQDN to be resolved  
> for determining which interface's DNS servers to use for a DNS query  
> (i.e. look for interface that is known to have the matching suffix).

that's a hint but not a general strategy, because it assumes a 1:1  
mapping between networks and zones.

> A host can also query (in parallel or in serial) through DNS servers  
> of different interfaces, but in that case it must not stop asking  
> when receiving negative response, as it may be that a DNS server of  
> another interface is able to reply positively.

That's the general strategy: "try all interfaces".

> When host gets an answer back, it should use source/destination  
> address selection algorithms in proper way - I comment on this also  
> on the draft. When I originally proposed host would use the DNS  
> suffix also for interface selection, there was negative comments  
> that DNS should not be involved in routing decisions.

You shouldn't use the DNS suffix. But you do need to have a certain  
stickiness between the interface that was able to resolve a DNS query  
and the interface that's used for subsequent data communication, at  
least as a hint.

But essentially, it's again "try all interfaces", because you may get  
multiple or even multiple conflicting DNS replies, and stuff still  
needs to work.

Lars

> Thus the current draft focuses on selecting right DNS server per  
> FQDN, after FQDN has been resolved to an IP address, it is for  
> source/destination address selection algorithm to continue from  
> there - which may not be trivial. Especially on IPv4 this may be  
> difficult, if e.g. public Internet facing interface is using RFC1918  
> private addresses, and private Intranet facing interface is using  
> the same RFC1918 addresses.
>
> Best regards,
>
> 	Teemu
> _______________________________________________
> mif mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mif

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 19 Mar 2009 10:16:19 +0100

>> suffix also for interface selection, there was negative comments that 
>> DNS should not be involved in routing decisions.
>

This is sounding more and more to NICE as Marck mentioned before....

>> source/destination address selection algorithm to continue from there 
>> - which may not be trivial. Especially on IPv4 this may be difficult, 
>> if e.g. public Internet facing interface is using RFC1918 private 
>> addresses, and private Intranet facing interface is using the same 
>> RFC1918 addresses.
>>
>> Best regards,
>>
>>     Teemu

---

From: Lars Eggert <[email-masked]>
Date: Thu, 19 Mar 2009 10:53:52 -0700

> This is sounding more and more to NICE as Marck mentioned before....

Yup. You don't know what works until you try, and there are some  
heuristics for trying in a smart order.

Lars