Subject: [mif] Updated Charter proposal

From: Hui Deng <[email-masked]>
Date: Thu, 5 Feb 2009 11:52:47 +0800

Hello all

I have updated charter based on the ML comments,
Please feel free to let us know the further step.

Thanks

-Hui

--------------------------------------------------
Background and Motivation

   A multi-homed host has multiple network interfaces (physical and/or
   virtual).  For example, a node may be connected to a wired Ethernet
   LAN, a 802.11 LAN, a 3G cell network, one or multiple VPN connections
   or one or multiple automatic or manual tunnels. Current laptops and
   smartphones typically have multiple access network interfaces. RFC 5113
   already specify basic "Network Discovery and Selection Problem".

   If there are multiple connections of the host, all the flows will go
   to the default gateway based on RFC1122 description when the host has no
   route cache entry for the destination host address of flows. One default
   gateway guarantees the host always has one entry to the network, but
   leads to difficulties when multiple connections are simultaneously
active.

   A multi-homed host receives node configuration information from each
   of its access networks.  Some configuration objects are global to the
   node, some are local to the interface.  Various issues arise when
   multiple configuration objects that are global to the node are
   received on the many interfaces the multi-homed host has.  Therefore,
   there is a need to define the appropriate behavior of an IPv4 or IPv6
   stack and possibly define protocols to manage these cases. RFC 3484
   proposed default address selection for IPv6 could be a refernce
   to this work.

Proposed Work:
-------------
The proposed mif Working Group will focus on the following topics
relevant for multiple interfaces:

 Split DNS:
   o A multi-homed host may have one of its interfaces facing a DNS
   service which resolves private names and addresses(Proposed Standard)

 Routing of multiple interfaces:
   o A multi-homed host may have multiple routes to a destination.
   However, by default, it may not have enough information to choose
   the best interfaces for different unicast applications/flows in the host.

   Thus a IPv4/IPv6 host would need to be provided with more information
   for interface selection which is different from RFC 4191(Proposed
Standard)

 Address Selection Policy:
   o a multi-homed host with IPv4 and IPv6
   connectivity might need to receive an update of its default address
   selection policy.  However, that policy is only valid within the
   context of the interface it received it from.  Each network on which
   the node is connected might have a different address policy to push
   to the connecting nodes"(Proposed Standard)

The BoF proposes to discuss the above items and gauge interest in
forming a working Group. There is already work in progress addressing
the identified problems, which is expected to be the starting point
for the deliverables.

The proposed activity will be complementary to the existing IETF
Working Groups, notably the DHC,6MAN and MEXT WGs.

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 05 Feb 2009 10:28:20 +0100

> Please feel free to let us know the further step.

I still think we need more clarifications on this one
For the new description, it seems that you are proposing to have 
different applications using different routes, is that the additional 
information that you are proposing?

If that is the case, i would suggest people to look into the work being 
done in MEXT in the flow binding topic, to see how solutions could look 
like and check if people want to go down this path

Regards, marcelo

> ------------------------------------------------------------------------
>
> _______________________________________________
> mif mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mif
>

---

From: Scott Brim <[email-masked]>
Date: Thu, 5 Feb 2009 09:50:58 -0500

> like and check if people want to go down this path

Marcelo, I think that's "stage 2".  That is, FIRST the node needs to
choose which interface to use for which flow, and then, IF it is using
MIP, then mext-flow-binding provides a vehicle for it to use different
interfaces in the MIP environment.  Regardless of whether a node is
using MIP or not, the interface selection problem exists.

Scott

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 05 Feb 2009 16:02:09 +0100

> using MIP or not, the interface selection problem exists.
I agree, i was not suggesting we use the MIP techniques as they are. My 
point was that we can similar approaches can be used in the non mip 
environment.

The proposed work is a mean to allow a some network entity (such as a 
router or a dhcp server) to convey information about which interface to 
use for whcih flow.

The work being done in MIP allows the HA to inform the MN/MR whcih flow 
to send through which interface.
This involves some form or lenguage to describe flows for instance This 
involves exchanging port and other upper layer information in a layer 3 
protocol. These seems to be common issues that are also present here.

My point that people can take a look about how this look like in mip, in 
order to materialize how this can be done (and maybe some work can be 
reused)

regards, marcelo

---

From: Jacni Qin <[email-masked]>
Date: Thu, 5 Feb 2009 23:52:22 +0800

Hi hui,

Some comments, please see inline

> Please feel free to let us know the further step.

== Is that to say simply, "multiple default routes with same metrics" ?

>    proposed default address selection for IPv6 could be a refernce

== Does it seem better to reword "global to the node" or "local to the
interface" to node-scope
or interface-scope, something? Just my personal advice. :-)

> Proposed Work:

== In the VPN case, for some implement traffic is forced to go through
the tunnel due to the one default route added.
Is it an approach (e.g. draft-savolainen-6man-fqdn-based-if-selection)
made to split the traffic to multiple connections, while some security
issues may be introduced, as access to the private network is
available through this point? Will it be out of the scope of MIF, or
be considered within the later policy related section?
What's our target for "Split DNS" ?

>    for interface selection which is different from RFC 4191(Proposed

== That means specific routes and preference of routers will not be
advertised according to RFC4191, there will be modifications
on the stack and the whole behavior described in RFC1122 ? Is it
transparent to upper layer applications ? meanwhile, keep it still
working for traditional single interface ?

> Working Groups, notably the DHC,6MAN and MEXT WGs.

More clarifications needed ? Still got a little confused on some points above.

Many thanks,

Jacni

---

From: <[email-masked]>
Date: Thu, 5 Feb 2009 17:28:58 +0100

>== In the VPN case, for some implement traffic is forced to go
>through the tunnel due to the one default route added.
>made to split the traffic to multiple connections, while some ....

>What's our target for "Split DNS" ?

Well my main point is to have more efficient DNS resolution: to send DNS name query to server most likely able to successfully answer to it. E.g. if corporation is using private names, send the DNS queries for private names to DNS servers in the intranet instead of some other DNS servers (e.g. those otherwise serving in the WLAN).

This can be achieved also by binding an application to use only specific network interface at a time, but for some applications like browsing it may not be the most efficient approach.

In -00 version of my draft I also proposed using domain name suffixes for actual interface selection, but that approach was rejected and it was said that host will be provided with more specific routes etc. that it should use for interface selection for an outgoing IP packet (instead of dns suffixes).

& another comment from Jari:

>This is a statement of fact. What work are you proposing?
>Please define what the PS RFC would change from today's situation.

Perhaps describing best currently available practices might be good as first step to show how existing technologies can be best utilized as solution for this.

Back to Jacni's email:

>made to split the traffic to multiple connections, while some
>security issues may be introduced, as access to the private
>network is available through this point? Will it be out of the
>scope of MIF, or be considered within the later policy related section?

I don't believe in future it will always be possible to allow only connectivity via the VPN interface - as e.g. how to handle VoIP (if it is hosted by someone else than the corporation VPN is used for) to work in that case?

The multi-interfaced host should not by default route traffic between VPN interface and other interfaces, but on the other hand security should not depend on that - a trojan horse controlling the host could anyhow create something-over-HTTP tunnel and by doing so provide routing services for outsiders to access private network - even while host seems to have just has VPN connection..

Best regards,

        Teemu

---

From: "Yong-Geun Hong" <[email-masked]>
Date: Fri, 6 Feb 2009 14:55:59 +0900

Hi,Teemu.

Inline please.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: Friday, February 06, 2009 1:29 AM
> To: [email-masked]; [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: Re: [mif] Updated Charter proposal
> 
> 
> >> Proposed Work:
> >> -------------
> Well my main point is to have more efficient DNS resolution: to send DNS
> name query to server most likely able to successfully answer to it. E.g.
> if corporation is using private names, send the DNS queries for private
> names to DNS servers in the intranet instead of some other DNS servers
> (e.g. those otherwise serving in the WLAN).

 => I think that it is a good idea. To handle DNS problems due to multiple
interfaces,
    it needs more smart DNS resolution. 

     RFC 4038 (Application Aspects of IPv6 Transition), section 3.2(DNS
Does Not 
     Indicate Which IP Version Will Be Used) might probably be related this
issue. 
 
    In RFC 4038, "The application should request all IP addresses without
address
    family constraints and try all the records returned from the DNS, in
    some order, until a working address is found.  In particular, the
    application has to be able to handle all IP versions returned from
    the DNS.  This issue is discussed in more detail in [DNSOPV6]."

    As same manner, application on the host with multiple interfaces should
request
    all DNS information without specific interfaces constraints and try all
the records
    returned from the DNS, in some order, until a working address is found
(if it is not
    possible to bind an application to use only specific interface at a
time) 

    But, it is better to bind an application to use only specific interface
if possible for efficiency.

    Over again, I agree that MIF must have more efficient DNS resolution. 

    Best regards.

    Yong-Geun.

> 
> This can be achieved also by binding an application to use only specific
> network interface at a time, but for some applications like browsing it
> may not be the most efficient approach.
> 
> In -00 version of my draft I also proposed using domain name suffixes for
> actual interface selection, but that approach was rejected and it was said
> that host will be provided with more specific routes etc. that it should
> use for interface selection for an outgoing IP packet (instead of dns
> suffixes).
> 
> Perhaps describing best currently available practices might be good as
> first step to show how existing technologies can be best utilized as
> solution for this.
> 
> Back to Jacni's email:
> 
> I don't believe in future it will always be possible to allow only
> connectivity via the VPN interface - as e.g. how to handle VoIP (if it is
> hosted by someone else than the corporation VPN is used for) to work in
> that case?
> 
> The multi-interfaced host should not by default route traffic between VPN
> interface and other interfaces, but on the other hand security should not
> depend on that - a trojan horse controlling the host could anyhow create
> something-over-HTTP tunnel and by doing so provide routing services for
> outsiders to access private network - even while host seems to have just
> has VPN connection..
> 
> Best regards,
> 
>         Teemu

---

From: <[email-masked]>
Date: Fri, 6 Feb 2009 14:40:08 +0100

Hi Hui,

Just a comment, please see inline.

Regards,
Pierrick 

> 
> ________________________________________
> De : [email-masked] [mailto:[email-masked]] De la part de Hui
> Deng
> Envoyé : jeudi 5 février 2009 04:53
> À : mif
> Objet : [mif] Updated Charter proposal
> 
> Hello all
> 

I'm wondering why you are limiting the scope to unicast. I mean, there are uses case for access selection, and thus routing issue, in case of multicast services (without talking about multicast mobility):

- Select the preferred access for multicast delivery 
or
- Access to the same content via multicast on one interface (e.g. DVB-H) or unicast on another (e.g. 3G). 

It leads to select the route for sending the appropriate service request, so same routing issue that describe in your text.

I agree that multicast is not the priority but maybe we should not exclude it explicitly from the charter.

---

From: Hui Deng <[email-masked]>
Date: Fri, 6 Feb 2009 23:46:06 +0800

Hi, Jacni

Excuse me for missing your email yesterday, thanks for your comments.
reply inline

2009/2/5 Jacni Qin <[email-masked]>

> == Is that to say simply, "multiple default routes with same metrics" ?
[Hui] Here would like state that even there are multiple default route,
normally host will choose only one other than same metrics issue
Anyhow, here need revision, thanks for your remindness.

> or interface-scope, something? Just my personal advice. :-)

[Hui] thanks, this would be fine,

> What's our target for "Split DNS" ?

This direction is principally not related to security issue, so it will be
out of the scope of MIF.

> working for traditional single interface ?

Difference here mean is not based on Router Advertisement.

> More clarifications needed ? Still got a little confused on some points
Thanks, will clarfiy soon.

-Hui

---

From: Hui Deng <[email-masked]>
Date: Fri, 6 Feb 2009 23:52:16 +0800

Hi, Teemu

Could you help to propose the new word regarding to Jari's comments?

Thanks

-Hui

2009/2/6 <[email-masked]>

> name query to server most likely able to successfully answer to it. E.g. if
> corporation is using private names, send the DNS queries for private names
> to DNS servers in the intranet instead of some other DNS servers (e.g. those
> otherwise serving in the WLAN).
>
> network interface at a time, but for some applications like browsing it may
> not be the most efficient approach.
>
> that host will be provided with more specific routes etc. that it should use
> for interface selection for an outgoing IP packet (instead of dns suffixes).
>
> hosted by someone else than the corporation VPN is used for) to work in that
> case?
>
> outsiders to access private network - even while host seems to have just has
> VPN connection..
>
> Best regards,
>
>        Teemu
>

---

From: Jacni Qin <[email-masked]>
Date: Fri, 6 Feb 2009 23:59:42 +0800

> otherwise serving in the WLAN).

That makes sense to me, thanks for your clarification.

> hosted by someone else than the corporation VPN is used for) to work in that

It might follow corporation's policy, e.g. traffic permitted should pass
through proxy inside the private network, or decided by users themselves?

> outsiders to access private network - even while host seems to have just has

Agree, and security issues should be considered when describing current
practices.

---

From: Hui Deng <[email-masked]>
Date: Sat, 7 Feb 2009 00:01:25 +0800

Hi, Pierrick,

Yes, I agree with you that it is not related multicast mobility
we should exclude multicast specifically, since how to choose source address
will be influcenced.  what does Behcet think about it?

thanks

-Hui

2009/2/6 <[email-masked]>

> I'm wondering why you are limiting the scope to unicast. I mean, there are
> uses case for access selection, and thus routing issue, in case of multicast
> services (without talking about multicast mobility):
>
> It leads to select the route for sending the appropriate service request,
> so same routing issue that describe in your text.
>

---

From: <[email-masked]>
Date: Fri, 6 Feb 2009 17:04:02 +0100

________________________________

De : Hui Deng [mailto:[email-masked]] 
Envoyé : vendredi 6 février 2009 17:01
À : SEITE Pierrick RD-RESA-REN; Behcet Sarikaya
Cc : [email-masked]
Objet : Re: [mif] Updated Charter proposal
 
Hi, Pierrick,
 
Yes, I agree with you that it is not related multicast mobility
we should exclude multicast specifically, since how to choose source address will be influcenced.  what does Behcet think about it?
 
[PS] do you mean "we should" or "we should not" ?
 
thanks
 
-Hui

Regards,
Pierrick

---

From: Hui Deng <[email-masked]>
Date: Sat, 7 Feb 2009 00:06:24 +0800

good catch, we should not,

thanks again.

-Hui

2009/2/7 <[email-masked]>

>
>
>
>   ------------------------------
>
> *De :* Hui Deng [mailto:[email-masked]]
> *Envoyé :* vendredi 6 février 2009 17:01
> *À :* SEITE Pierrick RD-RESA-REN; Behcet Sarikaya
> *Cc :* [email-masked]
> *Objet :* Re: [mif] Updated Charter proposal
>
>
>
> Hi, Pierrick,
>
>
>
> we should exclude multicast specifically, since how to choose source
> address will be influcenced.  what does Behcet think about it?
>
>
>

---

From: Jacni Qin <[email-masked]>
Date: Sat, 7 Feb 2009 00:16:46 +0800

Thanks for your reply.

On Fri, Feb 6, 2009 at 11:46 PM, Hui Deng <[email-masked]> wrote:

> ...

Ok, it's about more efficient name resolution, while should it be metioned
if there is a description of currently available pratices ? and the
same within the next "Routing of multiple interfaces" section ?

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 6 Feb 2009 09:17:40 -0800 (PST)

________________________________
From: "[email-masked]" <[email-masked]>
To: [email-masked]; [email-masked]
Cc: [email-masked]
Sent: Friday, February 6, 2009 10:04:02 AM
Subject: RE: [mif] Updated Charter proposal

De :Hui Deng [mailto:[email-masked]] 
Envoyé : vendredi 6 février 2009 17:01
À : SEITE Pierrick RD-RESA-REN; Behcet Sarikaya
Cc : [email-masked]
Objet : Re: [mif] Updated Charter proposal
 
Hi, Pierrick,

[PS] do you mean "we should" or "we should not" 
 
[behcet] It is clear that mif is Simple IP multihoming I thought concentrating on unicast applications' needs would help at this stage.
This has nothing to do with multicast mobility 
 
Regards,
 
Behcet

---

From: Hui Deng <[email-masked]>
Date: Sat, 7 Feb 2009 16:19:05 +0800

Hi, Behcet,

Both DHCP and source address selection will relate to multicast, MIF will
cover those.

but it is not related to mobility multicast,

thanks

-Hui

2009/2/7 Behcet Sarikaya <[email-masked]>

> *From:* "[email-masked]" <
> [email-masked]>
> *To:* [email-masked]; [email-masked]
> *Cc:* [email-masked]
> *Sent:* Friday, February 6, 2009 10:04:02 AM
> *Subject:* RE: [mif] Updated Charter proposal
>
>
>
>
> [behcet] It is clear that mif is Simple IP multihoming I thought
> concentrating on unicast applications' needs would help at this stage.
>

---

From: Hui Deng <[email-masked]>
Date: Wed, 11 Feb 2009 22:33:54 +0800

Hi, Jacni,

thanks, current pratice is ongoing.

-Hui

2009/2/7 Jacni Qin <[email-masked]>

>>  This direction is principally not related to security issue, so it will
>> be out of the scope of MIF.
>>
>

---

From: Hui Deng <[email-masked]>
Date: Wed, 11 Feb 2009 22:38:46 +0800

Hi, Yin

I guess that your email address has some issue with DNS name resolution.
Your email has been successfully subscribed to list.
You may have to use other email address, see reply inline below started with
"==>"

 Hello hui,

I'm new here. I have got a little confused on one point, please see inline.
==> thanks,

-LiuYin

2009-02-08
 liuyin08
> Please feel free to let us know the further step.

==When the different address policies are push to the connect node through
different interfaces, which policy the node use?
 ==> when different policy arrive the terminal, the connection manager will
merge them
together based on priority.

> Working Groups, notably the DHC,6MAN and MEXT WGs.
I'm new in the domain.

Thanks to give me help.

LiuYin
==Thanks for your comment

-Hui

---

From: "liuyin08" <[email-masked]>
Date: Thu, 12 Feb 2009 10:32:24 +0800

Hi, Hui

Thanks very much, and I will change my email address.
Best regards!

Liu Yin

2009-02-12 

liuyin08 

发件人： Hui Deng 
发送时间： 2009-02-11  22:38:48 
收件人： liuyin08 
抄送： mif 
主题： Re: [mif] Updated Charter proposal 
 
Hi, Yin

I guess that your email address has some issue with DNS name resolution.
Your email has been successfully subscribed to list.
You may have to use other email address, see reply inline below started with "==>"

Hello hui,

-LiuYin

2009-02-08 

liuyin08 

==When the different address policies are push to the connect node through
different interfaces, which policy the node use?
 ==> when different policy arrive the terminal, the connection manager will merge them 
together based on priority. 

I'm new in the domain.

Thanks to give me help.

LiuYin

-Hui

---

From: [email-masked]
Date: Thu, 12 Feb 2009 19:58:21 +0800

hi Hui:
 
  I read the chart of problem statement and I have 2 questions.

  1. will you add some classic scenario for clarification of 
multi-interface topic?
  2. will you have any security consideration about multi-interface topic 
?

  thanks 

  Best Regards

Terry(HongYan) Wang

---------------------------------------------------
Address: System Architecture Department, Central Institute, ZTE 
Corporation
Room 2A3, No. 68, Zijinghua Road, Yuhuatai District, Nanjing, China
Zipcode: 210012
Office Telephone: 
Mobile Telephone: +86-15905178852
Fax: +86-25-52878008
MSN: [email-masked]

Hui Deng <[email-masked]> 
发件人:  [email-masked]
2009-02-11 22:33

收件人
Jacni Qin <[email-masked]>
抄送
mif <[email-masked]>
主题
Re: [mif] Updated Charter proposal

Hi, Jacni,

-Hui

 
... 

Ok, it's about more efficient name resolution, while should it be metioned 
if there is a description of currently available pratices ? and the same 
within the next "Routing of multiple interfaces" section ?

> Working Groups, notably the DHC,6MAN and MEXT WGs.

More clarifications needed ? Still got a little confused on some points 
above.
Thanks, will clarfiy soon.
 
-Hui

Many thanks,

Jacni

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.

---

From: Hui Deng <[email-masked]>
Date: Fri, 13 Feb 2009 14:47:31 +0800

Hi, Yongyan,

Thanks for your comments,

reply inline:
2009/2/12 <[email-masked]>

>   1. will you add some classic scenario for clarification of

I guess future practice draft will cover the scenario.

>
>   2. will you have any security consideration about multi-interface topic ?
>

Normally each draft will have  independent security consideration section.

Best regards,

-Hui

> Address: System Architecture Department, Central Institute, ZTE Corporation
>   *Hui Deng <[email-masked]>*
> 2009/2/7 Jacni Qin <[email-masked]* <[email-masked]>>
> Thanks for your reply.
>
> On Fri, Feb 6, 2009 at 11:46 PM, Hui Deng <[email-masked]*<[email-masked]>>
> wrote:
> Hi, Jacni
>
> ...
>
> > [email-masked]* <[email-masked]>
> > *https://www.ietf.org/mailman/listinfo/mif*<https://www.ietf.org/mailman/listinfo/mif>
> >
> >
>
>