Multiple Interfaces (MIF) WG IETF 79, Beijing, China Margaret Wasserman Hui Deng

Note Well Any submission to the IETF intended by the Contributor for publication as all or part of an IETF Internet-Draft or RFC and any statement made within the context of an IETF activity is considered an "IETF Contribution". Such statements include oral statements in IETF sessions, as well as written and electronic communications made at any time or place, which are addressed to: - the IETF plenary session, - any IETF working group or portion thereof, - the IESG or any member thereof on behalf of the IESG, - the IAB or any member thereof on behalf of the IAB, - any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, - the RFC Editor or the Internet-Drafts function All IETF Contributions are subject to the rules of RFC 5378 and RFC 3979 (updated by RFC 4879). Statements made outside of an IETF session, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not IETF Contributions in the context of this notice. Please consult RFC 5378 and RFC 3979 for details. A participant in any IETF activity is deemed to accept all IETF rules of process, as documented in Best Current Practices RFCs and IESG Statements. A participant in any IETF activity acknowledges that written, audio and video records of meetings may be made and may be available to the public.

Logistics Note taker and jabber scribe Meeting materials (Slides, Agenda, etc) – XMPP Mailing list –

Agenda Agenda bashing (Chairs, 5 min) Documents with IESG (Chairs, 10 min) –draft-ietf-mif-problem-statement-05 >Responding to IESG Discusses and Comments –draft-ietf-mif-current-practices-02 >Responding to AD Review comments Current Practice Analysis (Chairs, 5 min) –draft-cao-mif-analysis-01.txt >Draft hasn’t been updated since 78 th Insufficient info to do analysis Solutions Work in Charter Other proposals

Agenda - Solutions Work in Charter 5.1 Split-DNS solution (Teemu, 10 min) draft-savolainen-mif-dns-server-selection-04 > Adopt this as a WG work item? 5.2 DHCP Route Option draft (Design Team, 10 min) > Do we have a draft that has design team consensus? > If so, adopt it as a WG document? 5.3 MIF api (Yuri, 10 min) draft-liu-mif-api-extension-03 > Conceptual API only > Adopt this as a WG work item?

Agenda - Other Proposals (If Time Allows) 6.1 Connection manager requirements (Gaetan Feige, 15 min) draft-seite-mif-connection-manager-02 > Focus on problems not solution requirements - Problem of connectivity to networks where authentication is needed for Internet access > How do we consider additional problems? 6.2 Holding the on-going sessions (Zhen, 5 min) draft-cao-mif-ongoing-session-00 > How does this related to problems in Problem Statement?

draft-ietf-mif-problem-statement IESG Review Don Romascanu > IEEE , acronyms Lars Eggert > QoS in the interface should not be considered by MIF Ralph Droms >I have a fundamental problem with the way in which this document characterizes the problems resulting from the simultaneous use of multiple interfaces as all resulting from receiving different configuration objects from different administrative domains. In my opinion, some of the example problems in the document are a result of other problems inherent with the simlutaneous use of multiple interfaces. This distinction is important because, again in my opinion, there are mif problems which cannot be solved by changes to the configuration behavior in the host. I see two ways to address my concern: either be explicit in limiting the problem statement and mif deliverables to those problems that can be solved with proper handling of configuration information from multiple admin domains or extend the scope of this document to include any problems that may result from the disparate environments (IP reachability, DNS resolution, QoS) to which interfaces are attached.

draft-ietf-mif-problem-statement IESG Review Adrian Farrel > Section 5, item 3 on routing, sub-bullet 2 describes an underlying problem attributed to routing. As routing is sued by this section, it seems to apply to host interface selection, first hop router selection, and general path selection. As written, the text seems an invitation for the MIF working group to delve into the issues of host control over routing path selection. Please do not go there. I sould suggest tightening the text up to make it clear that what is meant is policy based itnerface and first-hop router selection, where policy may reflect the many things listed in sub-bullet 2. Sean Tuner > Security Consideration 1)Lower layer authentication and encryption It's possible that some interfaces may have link layer or IP layer encryption and authentication. Its possible that this characteristic might be used in determining how configuration parameters are processed. Some connection managers may already do this to a certain extent. I think this should be listed as a consideration in the appropriate sections of the document (3.1, 3.6,5) 2) 2) I think the security considerations can be expanded It discusses that information may be leaked from one network to another which seems to be talking about generic data. This is true, but it seems that would be worthwhile to talk specifically about the information discussed in the document. For example it seems that it is at least possible for one interface to send configuration parameters that will cause a denial of service on another interface. It may also be possible for one host to set configuration parameters which cause certain traffic to be forwarded to an attacker.

draft-ietf-mif-current-practices-02 AD Review This draft got review comments from AD, we need more detail descriptions from each OS, if it is not sufficent enough, then we have to remove it from the document