[mif] MIF SFO Minutes

[Hui Deng <[e-mail]>]

Hi, all

Thanks Carl and Behcet's great help to take the minutes.
also thanks Remi Denis for Jabber

Please help to review and comment on it.

Best regards,

-Margaret / Hui

-----------------------------------------------------------------------

MIF BOF

The MIF BOF was held at IETF 74 San Francisco at 3:10pm on Thursday,
March 26, 2009 in Room Imperial B.

Chairs:
Margaret Wasserman and Hui Deng

1. Preliminaries                (5 mins Chairs)
   - Blue sheets
   - Note takers: Carl & Behcet
   - Jabber scribe: Remi Denis
   - Agenda

Hui: goes over the agenda. Only clarification questions during presentations

------------------------------------
2. Problem Statement presented by Marc Blanchet (10 mins)
http://www.ietf.org/proceedings/09mar/slides/mif-1.pdf
http://www.ietf.org/internet-drafts/draft-blanchet-mif-problem-statement-00.txt
http://www.ietf.org/internet-drafts/draft-yang-mif-req-00.txt
http://www.ietf.org/internet-drafts/draft-hong-mif-analysis-scenario-00.txt

Combination of drafts that detailed the problem statement was
presented by Marc Blanchet.

Margaret:  we only have an hour; only ask clarification question if
you are going to ask a question during the presentation.

Marc explained that the work began through discussions at last IETF in
Minneapolis.  The context here is to have a host that has multiple
physical interfaces or virtual interfaces – such as name your access
network ….. so you have multiple interfaces on host that are active
and they receive configuration information from their access network.

Marc noted that there are a few assumptions in this problem statement
– host has already discovered/select/authenticated into its access
networks along the lines of RFC 5113 and this is out of scope.  So the
point here is we are looking at the issues after this process when the
interfaces are enabled for IP traffic.

Question:  What do you mean by authenticated because there are some
packet networks where you may appear on some levels that you don’t
have an IP interface properly enabled yet.
Marc:  Authentication is to the point where you are enabled to do IP traffic.

Question. Then you are taking out 3G networks
Marc:  There is another discussion on this later on

Marc went on to say that other assumptions include that the host is
not a router and nor does the host necessarily run mobile IP or that
the host is stationary or mobile.

Marc stated that the information received on the interface may be
either interface scoped or node scoped.  He provided examples of
interface scoped information such as IP address and link prefix.
Routing information, DNS server addresses and address selection
policies are examples of node-scoped information.

Marc stated that the usually the Node Scope configuration objects may
become problem because you may not know on which interface that these
are valid.  So the symptom of the problem is that there is
insufficient or conflicting configuration results in traffic going out
of the wrong interface.  Wrong may mean that a particular service is
not available via that interface, or that even if it is, the path
chosen is not desirable for reasons such as security concerns, cost,
etc.

Marc went on to detail some examples of these issues.  He went over
DNS whereby each interface configuration object has different dns
servers IP addresses. He then went over Interface selection whereby a
node may have multiple defaults on multiple interfaces.  And in this
case the node or app may have no hint to decide which interface to
use.  He went on to state that there is no standard way for the
network to provide information to the node to choose an interface.
Address selection was another example whereby source addresses on some
access networks are not valid (in that they are not reachable on the
way back, filtered, …).  Here
Marc pointed out that not only choosing the right interface is a
problem but also which source address to use.

Marc concluded by stating that the problem is not new and different
implementation use different techniques to mitigate the stated problem
and pointed to the draft:  draft-mrw-mif-current-practices which
Margaret will present next.

------------------------------------
3. MIF Current Practices (Margaret Wasserman, 5 min)
http://www.ietf.org/proceedings/09mar/slides/mif-2.pdf
http://www.ietf.org/internet-drafts/draft-mrw-mif-current-practices-01.txt

Margaret noted that a revised -02 version was just posted before the
beginning of the BOF meeting.   Margaret went on to say that the goal
is to collect information about how current implementations operate
when they are configured with multiple physical or virtual interfaces.
Looking for additional information on current implementations so if
you know of one that is not in the document or have additional
information that is not present, please contact Margaret.  Margaret
said the goal of this task was to do a survey of what is out there and
to generalized or categorize current solutions.  Margaret went on to
say that the analysis is also intended to identify where there are
gaps that require some improvements. The work is still in progress and
goals are not yet completed.

Some systems currently included are: Nokia S60 3rd edition, feature
pack 2; MSFT windows Mobile 2003 2nd edition; Blackberry, Google
Android, Arena Connection manager, MSFT windows XP and Vista; Linux
and BSD Unix-based OS, and Apple Mac OS X.

Margaret pointed out there are two general approaches that operating
systems take in solving this problem.  The first of which is that the
application chooses a connection to use for a particular service and
that that particular connection will determine where all the traffic
associated with that connection is going to go.  It was pointed out
that this is most often done in the mobile/cell phone OSes that
Margaret saw.  How they choose that connection?  Most often they ask
the user.

Margaret went into how current implementations deal with DNS,
interface selection, default route,  and address selection, DNS server
list configured host-based or interface-based. DNS query sent up by
routing part of IP stack. Not tied to the interface from which config
info was received. Interface selection is a multi-step process.
Destination address on local link then do ARP and send locally. If
not, routing table is used. Next hop IP address and interface in the
route table is used. Default router list may be configured on a per
host basis. Sometimes per interface default router list is kept. No
good algorithm because source and destination address are not used
together.

Margaret needs more information on more implementations and needs to
group implementations and provide more consistent information about
them. Margaret said she would like to expand the common solutions
section.  Again, please let Margaret know or send text if you are
familiar with an implementation that is not included or have more
information about an included implementation.

Dave made a clarifying question/comment during Margaret’s presentation:
Dave Thaler:  Destination address selection rules in RFC 3484 are used
in at least one OS inside the name resolution APIs for returning the
order for they are returned to applications.  The applications don’t
do it but the rules in RFC 3484 apply to all applications by default
and there are flags in getaddrinfo() that specify control how they
behaves.
Margaret:  Send me quick note which OS.
Margaret says that she needs iPhone information.

Question:  HIP looks at table
Margaret:  Right.

Tim Chown:  From work you have done, do you have a list of stacks and
what they do and how they compliant they are with RFC 3484?
Margaret:  In the document we have each stack broken out and says what
it does. And we are still looking for more implementations.
Margaret is looking at shipping OS’s.

Question:  RFC 5014 api for interface selection. There are some rules
to override selection.
Margaret:  has it been implemented? Send me some text
Question: Yes there are some implementations like Linux but for Mobile IP.

------------------------------
4. Relationship to Other IETF work (Gabriel Montenegro, 5-10 min)
http://www.ietf.org/proceedings/09mar/slides/mif-3.pdf

Gabriel Montenegro presented relationship of this work to other IETF
work. Gabriel stated his presentation is dealing with how MIF is
different from other IETF efforts.
.Gabriel will look at different aspects of relationships of MIF BOF
problem with other IETF efforts.  Gabriel says that we are doing
overlapping things and commonality.  The other type of relationship
are those that are out of scope.

Gabriel laid out the different efforts including the in progress
efforts for RFC 3484 that a design team is currently working on.
Handling multiple interfaces in SHIM6, SCTP, MIP, HIP, RRG/LISP, PMIP,
Link Aggregation and Load-balancing and failover (LBFO).  Finally
there is the different flavors of address sharing across interfaces
(which he stated is out of scope of MIF).
RFC 3484 revision work is initially focused on site/enterprise
deployment scenarios multi-site multi-homing perspective.  They will
attack this problem as the priority.  If this becomes working group
this is a good place for requirements for multi-interface scenario as
MIF focuses on the node with multiple interfaces case.  Revision to
RFC 3484 should reflect both of these (and perhaps other)
perspectives.  Gabriel went on to say that the revision to RFC 3484 is
in scope of proposed MIF working group.  Including policy injection
from multiple interfaces and MIF would work with 6man working group
towards this.  But MIF also deals with other issues (e.g., DNS,
default gateway, ..).

Gabriel went over other protocols that handle multiple addresses or
interfaces.  He split them into two main approaches..For example via
one address or identifier there are: SHIM6, SCTP, MIP, HIP, RRG and
LISP.  As aggregated paths at the transport layer or above:  Trilogy
and Resource pooling at the transport layer.

Marcelo Bagnulo:  All these protocols as far as I understand don’t
deal with the initial contact and maybe MIF can provide that for them.

Gabriel:  Let’s look at what they all share with MIF. They assume they
have a peer that exists. We know someone who can talk their protocol.
How to choose src/dst pair to talk with peer, so that all can benefit
from RFC 3484 discussions (including better policy injection).  But in
doing so, each of the above efforts may depart from the RFC 3484
default.  MIF does not assume anything about the peer – whereas SCTP,
SHIM6, etc, assume the peer also implements that protocol.

Marcelo: all these protocols don’t deal with initial contact with the
peer. maybe MIF can provide that for them.
Gabriel: They share somethings with MIF. Proxy MIP based address
sharing across several interfaces used for mobility. But this is out
of scope.

---------------------------
5. Discussion (All, 20 mins)

Margaret : Wanted to make known questions she is going to ask the room:
            Question 1:   should we work on this problem in IETF?  .
            Question 2:   who is willing to work on this problem?

Comments/open discussion:
Comment:  On the related stuff we really need to look at BCP 38 –
Network Ingress Filtering.
Margaret: which one is that.
Response:  RFC 2827 Ingress Filtering.
Margaret:  Ok

Dave T.:  When you ask should we work on this problem in IETF do you
mean in a new working group or existing working groups?

Margaret:  This is not a working group forming BOF.  We want to get a
sense of interest on the problem and then we will determine where the
work goes and perhaps come back to list with charters or charter
amendments. Is there were we are – to Jari?

Jari: Yes, that is where we are at.

Dave T.: The problem statement is only a subset of real problems and
probable not the biggest part of the problem.  For example, interface
selection is one of the problems but is probable not the worst one.
There are other problems when you get configuration of host wide
parameters from other things say such as interface selection.  I am
thinking of things like how you operate a particular protocol over any
given interface using protocol version one or protocol version two
which isn’t address selection at all.  There are things like
acceptance use policy where this network says that you must not do X
on my network and you did X on network because you got host wide
parameters that you got from some place else and you may in violation
of that.  There are people who say this is interface selection and
some say that it is not.
It may be security issues for some cases like boot file option if you
are doing network boot and you have mutli-file thing and you choose
the wrong one you may be booting some  hackers boot image. There are
problems to be worked on but they are much wider than are listed in
the problem statement.

Jonne Soininen:  This is a problem to be worked on and this is a real
world problem.  I think that Dave said there are more problems but we
have to focus on something.  And even all these problems that were
presented in this BOF might be hard to solve in single solution.  We
need to focus this in the right way or divide the work in the right
way.

Christian Vogt:  main problem that it appears that people want to work
on is to do the initial selection of an interface when a connection
comes up.  I was also wondering if it makes sense to also think of a
handover scenario.  What should an application do if it finds that an
interface no longer works or this address no longer works – how does
it go and pick the next address.  I think that this is currently not
well documented and I think it would be very useful.  It would be
basically be guidelines for an application layer multi-homing if you
wish.

Suresh Krishnan:  I think that this problem is worth solving.  I think
we should investigate them further.  I think that Margaret’s
documentation of current implementations is quite admirable.  I think
this is very good progress for people who want to do and want to know
what works and what doesn’t work.  What would be nice for next
interesting work is to get more implementations getting documented and
also problem areas. I also want to work on this area.

Dave Oran:  I think that problem not properly formulated in the
following sense:  I don’t want my system to all of a sudden operate
completely differently depending on whether a single bit to tell me
that I am forwarding packets between two interfaces is turned on or
turned off.  So much of this applies equally to routers as it does to
hosts and we have these hybrid boxes – called home gateways –that have
split brains. Some things operate as a host and some things operate as
a router.  So I would like to see a taxonomy of the portions of this
problem that equally apply to routers as apply to hosts.  And the
portions of the problems that are in fact unique to coupling to the
higher layers in the box for the purpose of establishing IP
connections.

Bob Moskowitz:  In this discussion and moving forward I think it is
worthwhile to liason with IEEE 802.21 the handoff work there.  They
will have information that will be of value here and it so happens
that the IEEE 802.21 chairs are present here this week.

Tim Chown:  Likely frequency and triggers of such policy changes and
therefore looking at the frequency of the policy changes and the
appropriate methods to distribute the policy. But in parallel with
that it is also looking at the needs of RFC 3484 – there are things
that you can do now that involve no change in code just change in the
tables in a sensible way that there are other things that may involve
changes in code. There are things clearly going on here (MIF) that may
effect how policy tables or how the selection process can happen –
things that do involve changes to the code.  I think that both this
group and 6man will be looking this.  The relevancy of this to our
work is that we have an enterprise or a site where there will be hosts
that have information from multiple domains and therefore we have to
solve the conflict of policy issue that you mentioned.

Mark:  terrible effected by this.  Last thing want is new protocol
that is not working with existing access points. Not yet another
mobility kind of thing.  I agree with Christian… application should
work with this stuff.

Eric:  Some problem is really hard to solve such as different domain.

Dave T.:  How does the difference of parameters you get from an
administrative domain today  -which ones would be effecting
interoperability or application portability across platforms that
matter for some reason.  Which ones effect the use policy  - contact
between the host and the network that is trying to provide it.  Which
ones effect at security.   One of the potential work item is to go
through and say which one of these administrative objects you get and
which one of these gets inserted into one of these questions or some
other formed question.  If yes and then maybe some working group is
willing to work on.  And if the answer is no to all those, then maybe
we don’t care. So that is how we form open questions in my opinion.

Andrew:  it is worthful work to be done in IETF.

Marc: We believe this is a problem that we need to work on. We are
interested in case where you are connected inside different domains
like a corporate network and on carrier network mobile at the same
time.  We are willing to devote resources to work on this problem.

Tim Chown:  It is about the conflicting administrative domains. If you
had two links up you would assume that the site administrator is in
control of that and can set the policy accordingly.  We may develop
new methods to distribute information to hosts.

Ralph Droms:  Following to what Dave Oran said the differentiation of
classification of problems of host versus router and skip those things
that are specific to router is irrelevant.  I think that you must come
up with some other taxonomy for figuring out why this is important and
what the problems are of interest are. Secondly, just an observation
it is interesting that all of these problems are being brought
together here when in fact they are mostly problems that fall into
other work areas across all of the IETF.  I don’t know what to make of
that.  I don’t know how to make sure we get all these problems solved
but also drag in the right expertise from all the other places in the
IETF where this expertise happens.  Make sure that we don’t lose sight
of the fact that there are interesting problems in this particular
space  but that there lots of people in other working groups that
focus on where the solutions ought to be.

-----------------------------------------
6. Questions & Next Steps (Chairs/ADs, 10 min)

Margaret:  We have a couple of questions:
 Should we work on this problem in IETF, (yet, no, can’t tell).
Hands: many hands raised in response.  No official count taken.
No we shouldn’t. No hands.
Can’t tell. No hands.
Margaret:  Strong consensus we should work on ths problem. There are
20 people who say they will work in this area.  Jari will say some
last words.
Jari:  It is very clear we want to work on this area. First step is to
document what is available before working on policy distribution
protocols.