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

[Jari Arkko <[e-mail]>]

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 [http://tools.ietf.org/html/rfc5220" title='"Problem Statement for Default Address Selection in Multi- Prefix Environments: Operational Issues of RFC 3484 Default Rules"' rel="nofollow">RFC5220] in
the context of multiple prefixes on the same link.  New work
[http://tools.ietf.org/html/draft-ietf-mif-problem-statement-04#ref-I-D.chown-addr-select-considerations" title='"Considerations for IPv6 Address Selection Policy Changes"' rel="nofollow">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 [http://tools.ietf.org/html/rfc1122" title='"Requirements for Internet Hosts - Communication Layers"' rel="nofollow">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
[http://tools.ietf.org/html/draft-ietf-mif-problem-statement-04#ref-I-D.savolainen-mif-dns-server-selection" title='"DNS Server Selection on Multi-Homed Hosts"' rel="nofollow">I-D.savolainen-mif-dns-server-selection], [http://tools.ietf.org/html/draft-ietf-mif-problem-statement-04#ref-I-D.yang-mif-req" title='"Requirements on multiple Interface (MIF) of simple IP"' rel="nofollow">I-D.yang-mif-req] and
[http://tools.ietf.org/html/rfc4477" title='"Dynamic Host Configuration Protocol (DHCP): IPv4 and IPv6 Dual-Stack Issues"' rel="nofollow">RFC4477].

For example, as discussed
in [http://tools.ietf.org/html/draft-ietf-mif-problem-statement-04#ref-I-D.savolainen-mif-dns-server-selection" title='"DNS Server Selection on Multi-Homed Hosts"' rel="nofollow">I-D.savolainen-mif-dns-server-selection],
[http://tools.ietf.org/html/draft-ietf-mif-problem-statement-04#ref-I-D.hui-ip-multiple-connections-ps" title='"Problem Statement and Requirement of Simple IP Multi-homing of the Host"' rel="nofollow">I-D.hui-ip-multiple-connections-ps] and [http://tools.ietf.org/html/draft-ietf-mif-problem-statement-04#ref-I-D.yang-mif-req" title='"Requirements on multiple Interface (MIF) of simple IP"' rel="nofollow">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 [http://tools.ietf.org/html/rfc1122" title='"Requirements for Internet Hosts - Communication Layers"' rel="nofollow">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