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

[<[e-mail]>]

Hello Jari,

We have submitted a new version following your review. Sorry for the delay. 

Please see inline the details of modifications.

Best Regards,
Pierrick

> ________________________________________
> De : [e-mail] [mailto:[e-mail]] De la part de Jari
> Arkko
> Envoyé : mardi 8 juin 2010 15:55
> À : mif; [e-mail]; Marc Blanchet
> Objet : [mif] AD review of draft-ietf-mif-problem-statement
> 
> 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.
> 


Well, some items are not correct, or vague. At least, we should say that a MIF host can attach to more than one provisioning domains. An administrative domain could support more than one provisioning domain. So, we have rewritten as:

- A MIF host can attach to more than one provisioning domains, as presented to the IP stack.
- The configuration objects may come from one or more administrative domains.

> 
>    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.)
> 

Actually, without specific mechanism, it is not possible to configure same inet10 address on different interfaces. So, we consider that this situation is out of scope of the present document.

> 
> 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?
> 

NEW TEXT:

Some communications using these IP addresses are possible on all the    provisioning domains, while some are only possible on a smaller set of the provisioning domains.

> 
> 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]."
> 
> 

Ok, New text for section 3.3:

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.
> 
> 

New text:

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

> 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."
> 

NEW text addressing the 4 comments above:

3.5.  Finding and Sharing IP Addresses with Peers

Interactive Connectivity stablishment (ICE [RFC5245]) is a technique  for NAT traversal for UDP-based (and TCP) media streams established by the offer/answer model.  The multiplicity of IP addresses and ports in SDP offers are tested for connectivity by peer-to-peer connectivity checks.  The result is candidate IP addresses and ports for establishing a connection with the other peer.  However, ICE does not solve issues when incompatible configuration objects are received on different interfaces.  


Some application protocols do referrals of IP addresses and port numbers for further exchanges.  For instance, applications can provide reachability information to itself or to a third party. 

The general problem of referrals is related to the multiple interface problem, since , in this context, referrals must provide consistent information depending on which provisioning domain is used.
The general referral problem has been studied in [I-D.carpenter-behave-referral-object] and [I-D.ietf-shim6-app-refer], but no 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".
> 

NEW text:

Application Programming Interface (API) may expose objects that user
applications may use 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."
> 

Yes, this was the idea. So, we've rewritten as:

Connection managers usually leverage on API to gather information and/or for control purpose.  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".
> 
> 

Your're right, this section has no added value; we removed it.

> 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).
> 
> 

I agree. So, now section starts with:

Even if not yet specified, the distribution of address selection policy is sometimes evoked. If deployed, such a mechanism could bring specific issue in a multiple provisioning domain context.

> 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.
> 
> 

Ok for  "may be overwritten"

> 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.
> 
> 

That's right, the problem is that information is node scope and not tied to an interface. Anyway, section 5 has been revised for a better description of the problems.


>        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.
> 
> 

agreed, the Item has been removed

>        3.  Host implementations usually do not keep path
>            characteristics, user or provider preferences in the routing
>            table.
> 
> 
> Why would they?
> 
> 

These additional information could be used to select the path in a more intelligent manner. The text has been revised to clarify.

> 
>    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?
> 
> 

I understand; so, Section 5 has been revised accordingly. 

>    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.
> 
> 

I agree that the statement is not clear. 

> 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.
> 

I definitely agree. The suggested text is added, thanks.

> 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?
> 

OK, disclaimer for pre-RFC5378 work removed and replaced by trust200902

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

> 
> 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
> 
[snip]

All typos fixed.

[/snip]
> 

> 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.
> 
> 

Ok, references have been moved to ack section.

> 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...
> 

Revision of section led us to merge some items. Now, text related to "Type-of-Service in the routing table" is as followed:

Interfaces of a MIF host can provide different characteristics (e.g. round-trip time, least cost, better bandwidth, etc....). So, user, applications or network provider may wish to influence routing to take benefit of this heterogeneity. However, with current host implementations, neither the Type-of-Service nor path characteristics can be taken into account in the routing table.

> Jari