Subject: [mif] AD review of draft-ietf-mif-problem-statement

From: Jari Arkko <[email-masked]>
Date: Tue, 08 Jun 2010 09:55:29 -0400

I have reviewed this draft.

It has a good discussion of the problem space, but still needs some
work. My detailed comments are below. But the main issues from my
perspective are:

1) We need a crisper definition of the problems for Section 5

2) The definition of a MIF host needs to be tightened up.

3) The draft refers to MIF issues or purpose in several places as a
sort of a set of problems not yet solved by existing standards. I feel
that it would be better for the draft to talk about, say, problems of
hosts with multiple interfaces and include all the associated issues
even if they have already been solved or are being solved.

4) The draft is very centered around IP layer functionality, and has
minimal text about application functionality, middleware such as ICE,
and problems such as referrals. This part of the draft should be
expanded.

Technical:

A MIF host is defined as:

o  A [RFC1122] IPv4 and/or [RFC4294] IPv6 compliant host

o  Configured with more than one IP addresses (excluding loopback,

link-local)

o  On one or more provisioning domains, as presented to the IP stack.

o  The interfaces may be logical, virtual or physical.

o  The IP addresses come from more than one administrative domains.

o  The IP addresses may be from the same or from different address

families, such as IPv4 and IPv6.

o  Communications using these IP addresses may happen simultaneously

and independently.

o  Communications using these IP addresses may be tied on all the

possible provisioning domains, or, at least, on a limited number

of provisioning domains.

o  While the MIF host may forward packets between its interfaces,

forwarding packets is not taken into account in this definition.

Does this definition actually translate to a host with more than one IP
address from more than one administrative domains? The other conditions
seems explanatory rather than definitive.

o  Configured with more than one IP
addresses (excluding loopback,

link-local)

Do two identical net10 addresses on different interfaces count? (If it
is possible, not sure about that.)

o Communications using these IP addresses may be tied on all the
possible provisioning domains, or, at least, on a limited number
of provisioning domains.

I do not know what the above statement means. I cannot even parse the
English language here. Are you trying to say something about with whom
the communications of the host are with?

3.3. Mobility and other IP protocols

This document assumes hosts only implementing [RFC1122] for IPv4 and

[RFC4294] for IPv6, and not using any kind of new transport

protocols.  It is not required for the host to support additional IP

mobility or multihoming protocols, such as SHIM6, SCTP, Mobile IP,

HIP, RRG, LISP or else.  Moreover, the peer of the connection is also

not required to use these mechanisms.

RRG is not a protocol, and LISP is not affecting hosts.

And you should probably give some pointers to the already published
RFCs on multiple interfaces and mobility/idsplit designs.

But more importantly, I'm not sure the style of discussion is
appropriate here. You are not writing a requirements specification for
"MIF hosts" somehow separate from all other hosts in the Internet. Your
real point, I think, is that mobility and id/loc split mechanisms are
not considered in your analysis. If so, you could just write:

"This document is only concerned with the situation where the hosts
implement [RFC1122] for IPv4 and [RFC4294] for IPv6 and not
special-purpose support for transport layers, mobility, multi-homing,
or identifier-locator split mechanisms. Dealing with multiple
interfaces with such mechanisms is somewhat separate problem and under
active study elsewhere in the IETF
[RFC4960,RFC5206,RFC5533,RFC5648,I-D.draft-ietf-mptcp-architecture]."

Issues on using the Default Address Selection were found [RFC5220] in
the context of multiple prefixes on the same link. New work
[I-D.chown-addr-select-considerations] discusses the multiple
attached networks scenarios and how to update the policy table.

You should refer to RFC 5221 as well. Also, I think the I-D that you
want to refer to as new work is draft-ietf-6man-addr-select-sol.

ICE does not solve the MIF issues, such as the incompatible
configuration objects received on different interfaces.

While referrals feature does not
solve the MIF issues, it is related since,

At these points in the text you have not really defined "the MIF
issues".

ICE does not solve the MIF issues, such as the incompatible
configuration objects received on different interfaces. However, ICE
may be of use for address selection if the application is ICE-
enabled.

Mumble. I would argue that address selection is part of the MIF
problem. In any case, I think these types of statements need to move
away from "X does not solve the MIF problem" style to "X does A, B, and
C but not D or E" style.

Some application protocols do referrals (i.e. provides reachability
information to itself or to a third-part)

Perhaps you could pull the definition of a referral from somewhere. I
think the definition is wider than passing information to third
parties. For instance, storing information for your later use can also
be a problem.

Grobj

[I-D.carpenter-behave-referral-object] defines the problem with

referrals in today's IP networks.  While referrals feature does not

solve the MIF issues, it is related since, in a multiple provisioning

domain context, referrals must provide consistent information

depending on which provisioning domain is used.

This RFC should really stand on its own and describe the problem,
pointing to past solutions and ongoing efforts as needed. But
individual drafts and BOF proposals that went nowhere aren't very real
efforts that could you rely on in terms of solutions, for instance.
Perhaps you could just say that "The general problem of referrals is
related to the multiple interface problem, since ... The general
referral problem has been studied elsewhere
[I-D.carpenter-behave-referral-object] [I-D.ietf-shim6-refer], but no
real solutions exist today."

Application Programming Interface (API) may expose objects that user
applications may use for the MIF purpose.

"The MIF purpose" is not defined yet. Perhaps you could just have said
"... for dealing with multiple interfaces".

If examples exist, as
reminded above, there is no set of high level API to provide all
required services for a connection manager expected to address IP
configuration issues in a context of multiple provisioning domains.
Moreover, various operation system implementations deliver different
sets of high level API.

I cannot parse this text. Perhaps you wanted to say:

"However, there is no standardized high level API, and implementations
differ also in the functionality that they provide."

3.7. Above IP Layers

The MIF issues discussed in this document assume no changes in

transport protocols or applications.  However, fixing the issues

might involve these layers.  For instance, an application may

implement the connection management function (as decribed in

preceding section).

This section has multiple problems. First of all, the assumptions about
not dealing with multihoming mechanisms was already stated earlier.
Secondly, the document itself states that ICE and application logic is
used to solve some issues related to multiple addresses, such as
address selection. You could argue that Section 3.5 is all about "above
IP layers".

4.1. DNS resolution issues

This section should also deal with search path issues. In addition to
server addresses, you will also receive DNS search paths via DCHP or
RAs. "a" might resolve under the search path, but again, search paths
for different interfaces may differ.

A MIF host (H1) has an active interface(I1) connected to a network
(N1) and another active interface (I2) connected to a network (N2).
When the user or the application is trying to reach an IP address
(IP1), the following situations may occur:
H1 receives from both networks (N1 and N2) an update of its
default address selection policy. However, the policies are
specific to each network. The policies are merged by H1 stack.
Based on the merged policy, the chosen source address is from N1
but packets are sent to N2. The source address is not reachable
from N2, therefore the return packet is lost.

Unlike the other issues discussed in the draft, this one is somewhat
speculative, given that there are few deployed or even specified
address selection policy distribution mechanisms. It might be good to
prefix this paragraph with some statement that such mechanisms are
under development (or pointers to the existing ones, if they exist).

2. Same configuration objects (e.g. DNS server addresses, NTP
server addresses, ..) received from multiple provisioning
domains are usually overwritten.

"usually" -- I don't know if that's really the case. Does the existing
practices document support this conclusion? If you are not sure about
this, use "may be overwritten" instead.

2. Same configuration objects (e.g. DNS server addresses, NTP
server addresses, ..) received from multiple provisioning
domains are usually overwritten.
3. Host implementations usually do not keep separate network
configuration (such as DNS server addresses) per provisioning
domain.

But isn't the problem even more fundamental? There is really no concept
of a provisioning domain as far as the host is concerned. It just gets
information from multiple interfaces, routers, or DHCP servers, and has
no idea what the relationship of the information might be. For
instance, you could get default router and DNS server 10.0.0.1 from two
interfaces, i.e., exactly the same information on both sides but it
could still be two different domains and two different devices on the
other end.

4. Referrals must provide consistent information depending on
which provisioning domain is concerned.

I'm not sure this belongs under configuration problems. I think
referrals are a free-standing problem.

3. Host implementations usually do not keep path
characteristics, user or provider preferences in the routing
table.

Why would they?

2. DNS resolution
1. DNS server addresses are usually node-scoped.
2. DNS answers are usually not kept with the interface from
which the answer comes from.

I feel that Section 5 is not doing a good enough job in nailing down
what the real problem is. This is apparent in all the describes
problems, but I'll illustrate the issue with the DNS text above. You
make two statements, both of which are facts. But you do not draw the
final conclusion. Why do these facts lead to some breakage?

3. Host implementations usually do not implement the strong host
model [RFC1122] where the source address is in the routing
table.
4. Applications usually do not use advanced APIs to specify the
source IP address or to set preferences on the address
selection policies.

Are you suggesting that mere switching to a strong host model would
remove the problems?

Also, item 4 is more about moving the problem around than really
solving it. IP layer doesn't employ policies, because it doesn't have
the information. Applications wouldn't necessarily have the information
either.

7. Security Considerations

The problems discussed in this document have security implications,

such as when the packets sent on the wrong interface might be leaking

some confidential information.  Moreover, the undetermined behavior

of IP stacks in the multihomed context bring additional threats where

an interface on a multihomed host might be used to conduct attacks

targeted to the networks connected by the other interfaces.

I would also add that attempts to provide more information to the host
so that it could make a more intelligent decision would bring
additional security concerns about protecting this additional
information in some manner.

Editorial:

ID nits results, please look if these need action:

-- The document has a disclaimer for pre-RFC5378 work, but was first
submitted on or after 10 November 2008. Does it really need the
disclaimer?

== Outdated reference: draft-ietf-mmusic-ice has been published as RFC 5245

These mechanisms are not standardized and do
not necessarily behave
the same way across different OS, and/or platorms, in the presence of
the MIF problems.

Typo: platorms

of its access networks, through various
mechanims such as DHCPv4

Typo: mechanims

For instance, an application may implement the
connection management function (as decribed in preceding section).

Typo: decribed

S2 responds with an error for an non-existant
domain (NXDOMAIN).

Typo: existant => existent

has better characterictics, such as better
round-trip time, least

Typo: characterictics

provisioning domain (e.g. according to
avalaible QoS).  Each

Typo: avalaible

Or, when dealing with different domain
selection policies, a connection
manager may give precedence to user policy while another could favour
mobile operator policy.

Typo: favour => favor

0ne administrative domain can contain multiple
provisioning domains.

Typo:  0ne => One

A MIF host is defined as:

The acronym MIF is not expanded anywhere in the document. Note that
once the working group has completed, the RFCs need to stand out on
their own and still be understandable.

Some application protocols do referrals (i.e. provides reachability
information to itself or to a third-part)

Typo: third-part => third party

These situations are also described in
[I-D.savolainen-mif-dns-server-selection], [I-D.yang-mif-req] and
[RFC4477].

For example, as discussed
in [I-D.savolainen-mif-dns-server-selection],
[I-D.hui-ip-multiple-connections-ps] and [I-D.yang-mif-req], a
service provider might want to influence the routing table of the
host connecting to its network.

These sorts of notes would be better off in the
contributor/acknowledgments section than in the middle of the text.
Remember that the RFC has to be readable years from now, and by the all
knowledge of other I-Ds may have disappeared.

This section tries to list the underlying problems corresponding to
the issues discussed in the previous section.

This section lists the ... (you should have confidence that you have
described the problems correctly!)

2. Host implementations usually do not implement the [RFC1122]
models where the Type-of-Service are in the routing table.

Something wrong with the sentence. Type-of-Service field is considered
in the routing table, maybe...

Jari