2.4.14 Site Multihoming in IPv6 (multi6)

NOTE: This charter is a snapshot of the 58th IETF Meeting in Minneapolis, Minnesota USA. It may now be out-of-date. Last Modified: 2003-10-16
Chair(s):
Sean Doran <smd@ab.use.net>
Kurt Lindqvist <kurtis@kurtis.pp.se>
Operations and Management Area Director(s):
Randy Bush <randy@psg.com>
Bert Wijnen <bwijnen@lucent.com>
Operations and Management Area Advisor:
Randy Bush <randy@psg.com>
Mailing Lists:
General Discussion: multi6@ops.ietf.org
To Subscribe: majordomo@ops.ietf.org
In Body: subscribe multi6
Archive: http://ops.ietf.org/lists/multi6
Description of Working Group:

A multihomed site is a site that has more than one connection to the public internet with those connections through either the same or different ISPs. Sites choose to multihome for several reasons, especially to improve fault tolerence, perform load balancing, etc.

Multihoming today is done largely by having a site obtain a block of address space and then advertising a route for that prefix through each of its ISP connections. The address block may be from the so-called provider independent space, or may be a sub-allocation from one of its ISPs. A site's ISPs in turn advertise the prefix to some or all of their upstream connections and the route for the prefix may propagate to all of the routers connected to the default-free zone (DFZ). As the number of sites multihoming in this manner increase, the number of routes propagated throughout the DFZ increases and overall routing stability decreases because of the burden on convergence time. This WG will explore alternative approaches with better scaling properties. Specifically, the WG will prefer multi-homing solutions that tend to minimise adverse impacts on the end-to-end routing system and limit the number of prefixes that need to be advertised in the Default-Free Zone (DFZ).

This WG will consider the problem of how to multihome sites in IPv6. The multihoming approaches currently used in IPv4 can of course be used in IPv6, but IPv6 represents an opportunity for more scalable approaches. IPv6 differs from IPv4 in ways that may allow for different approaches to multihoming that are not immediately applicable to IPv4. For example, IPv6 has larger addresses, hosts support multiple addresses per interface, and relatively few IPv6 address blocks have been given out (i.e., there are no issues with legacy allocations as in IPv4).

The WG will take on the following initial tasks:

Produce a document defining what site multihoming is, the requirements for a multihoming solution (from both the end site and ISP perspective). This document will also include a taxonomy of different ways that multihoming might be achieved.

Produce a document describing how multihoming is done today, including an explanation of both the advantages and limitations of the approaches.

The WG will also consider specific proposals to multihoming in IPv6 (both existing and new) and select a small number of them to work on as formal WG items. Development of specific solutions will require approval of the IESG (e.g., a recharter).

Goals and Milestones:
Apr 01  Submit initial I-D on requirements, terminology, etc.
Apr 01  Submit I-D on how multihoming is done today
Apr 01  Begin consideration of approaches and proposals that could be pursued.
Aug 01  Evaluate approaches and select those to be worked on.
Sep 01  Submit requirements ID to IESG for publication as Informational RFC.
Sep 01  Evaluate progress, recharter or shutdown
Sep 01  Submit 'how multihoming is done today' ID to IESG for publication as Informational RFC.
No Current Internet-Drafts
Request For Comments:
RFCStatusTitle
RFC3582 I Goals for IPv6 Site-Multihoming Architectures

Current Meeting Report

Multi6 Working Group - IETF 58

Session 1
Tuesday 11 November
Agenda:
  • Agenda Bashing and Administrivia
  • Design Team 2 Update
    • Marcelo Bagnulo / David Kessens
  • Dave Crocker
    • draft-crocker-mast-analysis-01.txt
    • draft-crocker-mast-proposal-01.txt
  • Arifumi Matsumoto
  • Masataka Ohta
    • draft-ohta-multihomed-isps-00.txt
  • Kenji Ohira
    • draft-ohira-assign-select-e2e-multihome-02.txt
    • some research results about implementation of SABR
Session 2
Wednesday 12 November
Agenda:
  • Erik Nordmark
    • draft-nordmark-multi6-noid-01.txt
    • draft-nordmark-multi6-sim-01.txt
    • draft-nordmark-multi6-threats-00.txt

Agenda Bashing and Administrivia

Scribe: Geoff Huston WG Chair announcement: Sean Doran has stepped down as co-chair of the Working Group. Brian Carpenter is co-chair for the working group for this week. Shortened agenda for Tuesday to allow a break to attend the IPv6 WG meeting RFC3582 (Goals for IPv6 Site-Multihoming Architectures) to measure proposals has been published. Each presenter has been asked to measure their proposal against the parameters described in this document

Decisions / Outcomes

  1. The WG should evolve the threat work (as documented in nordmark-multi6-threats) with solution development.
  2. Chairs to set a date for the submission of ideas regarding approaches to multi-homing - mid-January appears to be the preferred deadline.
  3. Take the topic of evaluation criteria for WG to use to the mailing list.
  4. Eliot Lear to prepare a draft on criteria for analysis of MH proposals.
  5. Jim Bound to draft a proposal using SCTP + NOID with TCP emulation layered above SCTP.
  6. Pekka Nikkander to prepare a HIP based MH draft.
  7. WG to consider how to converge ('marry') these proposals into a WG proposal from this set of individual proposals using an approach of functionality analysis of the proposals.

Presentations

Design Team 2 Update

Presentation
  • Design Goals outlined, with a reduced set of requirements as described in draft-huitema-multi6-experiment-00. The approach described as incremental with minimal changes to external hosts.
  • testbed described
  • Normal Operation - source address based routing, load sharing and policing
  • fault Tolerance - 2 cases: outage in link between mh sites and direct ISP - RFC3178. Outage in other elements is reference to RFC3484 from externally-initiated comms. Internal initiated communications retry with a difference source address
  • summary - a lot of features that only require some additional configurations. Internal hosts require modifications for internally- initiated communications. External hosts require changes to preserve comms in external-initiated communications
  • The capability against RFC3582 presented
Clarification questions:

How is the ingress filtering from the ISPs circumvented?
Source address-based routing in the site's boundary routers - packets will be forwarded from one exit router to another based on source address.

How would this work if the routers were not on the same subnet?
The model assumes a subnet in this presentation, and the remote case may require additional internal routing capabilities

Design Team 1 Update

Presentation
  • extensive update provided in Vienna - this one is more succinct. Erik Nordmark will cover the substantive issues in the subsequent WG sessions
  • the essential element is the use of explicit identifier / location identifier split using a shim layer to map between the two identity spaces.
  • the design team is considering a number of aspects: threats,
  • threats to be addressed in next session
  • issues similar to mobility in v6, but mobility approaches can't be directly mapped due to multi-homing differences
  • NOID
    • no identifier beyond FQDN. FQDN is not to be loaded into packets, and upper layer protocols chose a locator and the shim layer allows the upper layer to continue to use this locator even in the event of home changes.
  • CB128
    • the shim layer performs a reverse -> forward -> reverse DNS lookup
    • another approach uses a 128 bit crypto-id, similar in some form to the HIP approach, but with different mechanisms.
    • locators can't be found from IDs in this case
  • CB64
    • alternate approach with 64 bit hashes
  • cryptoid
    • similar to cb64 with internal structure within the identity space. Locator and ID bits can appear on the wire.

Analysis

Dave Crocker
  • framework for the approach is a similarity in multi-homing and mobility. The stated difference is one of the time base for the multiple addresses in play.
  • lengthy considerations sections
  • infrastructure approach uses an agent that works on behalf of one end of the communications
  • shim or wedge is a full function layer that sites only in the end- points, not in the transit operation. Mast is one of these. HIP is another, and there are some other 4 or 5 noted. The end-to-end communications is without intermediaries. The shim layer is a rendezvous-styled operation
  • transport layer approaches
  • comparisons of these approaches include the match against the goals document, and it is claimed that there are more considerations here.

MAST

Dave Crocker
  • goal of maintaining locator pools. The application's awareness of the locator pool is mute. Claimed to make renumbering easier
  • terminology listed. multi-addressing is claimed to be relationship across multiple packets that pass across the infrastructure.
  • identifier to locator mapping is one aspect. locator selection is an open research topic, if there is more that one locator.
  • architecture knowledge of multiple locators goes to endpoint modules within the host, but no further. The endpoint module will map from an eid string to a locator. Each host loads its locator as an 'open question'. NAT traversal is described by a mirror query to the remote end to locate the own external locator. DNS and presence is included as a means of getting a current locator using a presence- style service.
  • operator - locator discovery and locator selection. The discovery operation is 'normal' DNS for fixed. DNS + dynamic mechanism to retrieve current locator. Locator interruption can be undertaken by MAST peer-to-peer
  • locator pool maintained through MAST mechanism
  • security only equal to IP. The recognition of 2 packets belonging to the same sequence have a number of choices. For global persistency global DNS is proposed. A NONCE is proposed to be sufficient for mobility
  • table of comparison presented.

TCP Multi-Home Option

Arifumi Matsumoto
  • DT2 - host-centric model, source-address based routing within mh site. Improved TCP is necessary and claimed to be simple. SCTP is not TCP as there is no interoperability between SCTP and TCP endpoints in a single session. This approach is TCP MH Options
  • TCP - add MH option only. claimed to allow rapid recovery from transmission failure. after RTO timeouts the pool of source addresses is used to use a new path
  • protocol exchange illustrated. SYN packet contains MH option that includes the intention to use different source addresses.
  • bit format for MH options presented.
  • path switch triggered on TCP timeout or ICMP error path discarded under certain conditions
  • security considerations: redirection attack - claimed to be easily prevented in this approach. Session hijack protected by strict MH- Serial number management, backing out when incorrect serial received.
  • not the consensus of the DT2 team.
  • table of comparison presented
Clarification questions:

What to do with UDP?
UDP need not be considered within this context.

Why are TCP enhancements is showing up here first? This should be targeted at transport area!
(Chair) This would be referred over if we proceed in this way.

Redirection attack is possible on guessing the 16 bit number. Protection is based on not being able to guess this 16 bit number, correct?
yes, although there are other protections here to reset the TCP session

Global Routing Table Size

Masataka Ohta
  • the goal in multi6 is to make the global routing table small
  • how small at the lower limit?
  • small routing table is claimed to be a desirable goal
  • mh is multiple links with separated sites for boundary routers
  • full route sets are necessary on the 'site backbone'
  • a full routing table on hosts allow a host to carry unreachable locators and metrics for each locator
  • source locators must be 'proper'
  • let hosts select the source locator, routing protocol to carry source locator to be used for each destination
  • policy control is 'not so global'
  • the global routing table size should be larger than the number of Tier 1 ISPS. An upper limit should be imposed by memory and bandwidth of a host. Presentation makes some assumptions to calculate this figure, and postulates that the global routing table should be upper limit bounded at 8,000 entries in the global routing table.
  • table of comparisons

Source-Based Routing

Kenji Ohira
  • characterizes some solutions as above IP and below TCP, others are TCP augmentation /alteration
  • target is small stub networks, not ISP multi-homing
  • method proposed of hierarchical addressing and source-based routing
  • updates from original draft listed
  • table of comparison provided

Lin6

Masahiro Ishiyama
  • location in dependent networking
  • implementations
  • uses globally unique id in low 64 bits and network prefix in upper 64 bits
  • locator resolution uses a new agent - a mapping agent - to perform this resolution
  • assume that the ID is statically assigned - now working on a dynamic assignment mechanism with a crypto base with the mapping agent

Multi6 Threats

Erik Nordmark
Why?
  • adding this additional level of indirection to the architecture opens up security vulnerabilities
  • can be used to divert traffic and potential denial of service to a 3rd party
  • similar to mobile ipv6, but not identical
Today's assumptions
  • how good security - no better, but not making it any worse
  • option to use the DNS and trust what comes back
  • applications that trust the source IP addr of received packets without any verification of information - these are vulnerable to various forms of attack
  • the existence of reverse+forward DNS resolutions was noted
  • using security mechanisms and their notions of identity
  • opportunistic security without access control
Redirection threats today
  • compromise the routing protocol
  • compromise the DNS
  • ND/ARP spoofing
  • attack a node on the path
  • mh solution should not make things any worse
Flooding attacks today
  • send packets to target
  • self-flood or flood path to self (e.g. ACK spoofing)
  • reflection attack where A can direct B to send to C, with out without amplification
  • we don't need to fix these problems, but should avoid making them worse
New attack vectors
  • redirect existing flow to a new locator
  • predictive attack (if A will talk to B, C claims to be A before A communicates with B)
  • replay attack
  • black hole by broadcasting a broken id/locator binding
3rd party DOS attacks
  • redirection to flood a 3rd party
  • possibly a check that the endpoint is reachable at the location prior to data flow as a mitigation
Accepting Packets
  • With ingress filtering at all locations its hard to inject a spoofing packet
  • mh potentially allows any source, compromising ingress filtering

Multiple Multi6 Approaches

Erik Nordmark
  • A number of solution proposals with inherent trade-offs
  • NOID, SIM and CB64 as a shim between ULP and IP, below fragmentation, AH, ESP and destination options, and above IP 'routing'
  • Application / ULP uses an ID that is stable for a session or longer. This IS is termed the 'AID'
  • mh uses different locators over time
  • rewriting of source locators to detect changes
  • Uses DNS without changes
  • NOID
    • no identifier in any packets. The FQDN is the node identifier, and a set of locators are used on the wire.
    • The ULP uses a single locator during a communications
    • different connections use different locators to allow load-sharing
    • shim layer can use different locators on the wire
    • receiver needs to rewrite locator according to current context
  • NOID - DNS
    • uses reverse + forward to prevent redirection attacks
    • this provides the FQDN and a working reversed
    • without this you cam communicate with a mh NOID remote point but cannot be mh yourself
    • needs R6 RR into the DNS
    • no packet overhead for data packets
    • uses flow id plus next header values
    • conceptually this is similar to an extension header to operate at the shim layer
    • new ICMPv6 packets for the handshake
    • NOIDS walk through in presentation
  • SIM concepts
    • 128 bit identifier, a hash of a public key, akin to HIP, created autonomously
    • Upper Layer Protocol uses these identifiers
    • shim layer needs a context tag, and is seeded from the DNS
    • AAAA records plus new SIM ID RR type to collect identifier
    • In order to prevent redirection, the public key crypto scheme is used, as per CGA in SEND WG. Not needed until locators change.
    • Also uses an explicit extension header
    • new packets for handshake
    • protocol exchange walk through
  • CB64
    • middle ground between NOID and SIM - IP addresses with 64bit hash of a public key
    • previously discussed in SEND and MobileV6
  • High Level choices:
    • Is it beneficial to introduce a new IP space as in SIM/HIP
    • Or use multiple addresses
    • DNS for verification issues? vs public key crypto? or no verification?
    • Use of local locators?
Clarification questions:

Do you assume symmetric routing in these models?
No.

Do you assume DNSSEC in these models?
No - but use of DNSSEC would improve the security of the use of DNS

For SIM you claim no PKI is required, but a new DNS RR is returned - Is this a public key record?
No keys are stored in the DNS in this approach. Its a derivative rather than the actual key. The trust in DNS is no change

The threats work said "don't make things worse". Those protocols are being secured right now. To what version of these protocols are you referring to - secured or unsecured?
If introduced today, we don't want to make things worse than today, or in the future.

General Discussion

3.1 Cutoff date for Proposals?

Kurt Lindquist (chair): The issue is for how much longer do we keep on seeing the same presentations. The cutoff for proposals to be submitted as drafts for WG consideration is proposed by the chairs to be year end.

Brian Carpenter (chair): Call for comment on this proposed rule

Keith Moore: Serious reservations for this call. Nothing is serious enough in the proposals to be a 'real' solution. IN the past a late proposal has been a drastic improvement with eager WG adoption. Its premature to reduce the number of proposals.

Jim Bound: Process point: I've read the specs - I don't need to hear this.

Matsataka Ohta: This is fine for my proposal, but no good for others as it promotes a step-by-step approach. The NOID approach does not address interaction with mobility, for example.

Brian Carpenter: The proposals so far are not ready for evaluation, but I'm not willing to accept more - they are two different points. I don't know any way to make things happen without deadlines. If no deadline then we will never complete the proposal stage.

Erik Nordmark: The thing you want to avoid is new proposals that are similar to previous proposals in all but name. But different ways of doing things should not be cut off. Maybe look at diffs to current proposals rather than complete proposals

Eliot Lear: 31 Dec is very close. If so then why not make the proposal cut today?

Brian Carpenter: we are aware of one draft that did not make it.

Eliot Lear: Could you please include HIP is this set of proposals for WG consideration?

Keith Moore: The scheduling concern is fine for understood problems. But if the problem is not understood, then setting deadlines for proposals is not a solution path

Christian Huitema: What concerns me is the focus on proposals. So far there are complete architecture presentations, and no modular approach has been presented so far. Maybe modularity of the solution process would help. Some things are constant/generic - eg ingress filtering, security. None of the solutions seen so far provide for incremental deployment - none have a business model that drives incremental deployment.

Brian Carpenter: This concept of a cutoff date for proposal is not being accepted by the WG. Instead could we set a target date for ideas to get ideas out so we avoid a situation where everything arrives at a face-to-face meeting. Reasonable?

WG: silence and nods

Decision: Chairs to set a date for the submission of ideas regarding approaches to multi-homing

3.2 Evaluation Criteria

Randy Bush: we need to consider what e2e connection setup, referrals (passive ftp), both ends attempt simul connect. NOID appears to be incompatible with local addressing or two-faced DNS - I'm not sure that this is a bad thing

Kurt Lindquist: Remind the WG on desired properties of a solution (see slide) How to pick a proposal? RFC 3582 is one tool to do so

Brian Carpenter: Some of these questions raised are missing in that RFC - the WG may want use a longer list of criteria

Kurt Lindquist: At some point we still need to pick a solution - we'll take this to the mailing list to discuss these in depth - more merit may be an outcome of combining aspects of these proposals

Decision: Take the topic of evaluation criteria for WG to use to the mailing list.

3.3 General Discussion of Proposals

Erik Nordmark: thinking about how referrals work is very important - each approach is different. Technical differentiator. In NOID, The extra 8 bytes uses the flow id on the proposal. If you believe that the rewriting of the ID by the receiver is good, then some help in the header to flag this permission would be good.

Brian Carpenter: If we go down the path of this solution we should discuss the version number at some stage

Erik Nordmark: 2 faced DNS and local addresses. NOID says you get the id info from the DNS. Added words suggesting what happens when you get inconsistent answers from the DNS? Maybe you need a mechanism to exchange the info you received. Or maybe sprinkling in some other security technique into this may be useful. This has not been explored in any detail.

Matsataka Ohta: I like my own security requirement drafts. I have objections to his draft. redirection attack. The other concern is that the security analysis is complete.

Brian Carpenter: please distinguish between threat analysis and solution

Tony Li: Our proposal ensure incremental deployment by allowing each host to advertise its capabilities.

Ilijsch van Beijnum: There are proposals where you need to store info in the DNS that are not there today. Proposals to allow systems to interact before interaction. Both at the same time is not ok.

Keith Moore: Use of DNS - likely that DNS is part of any successful proposal. DNS names are service names as well as host names. not just host names. Rebinding to the DNS IP addr is a dubious assumption. In practice DNS is not universally consistent. Assuming that DNS is a good mechanism for addressing updates and changes is not a good assumption.

Brian Carpenter: use of reverse DNS tree?

Keith Moore: That would be unwise.

Jim Bound: Did not understand the use of compression in the flow-id. The SCTP protocol combined with NOID may well be the answer. I'd IKE to propose a submission to the WG on SCTP + NOID.

Brian Carpenter: As SCTP is not TCP this would imply that there would be no TCP in your approach

Jim Bound: I had in mind SCTP simulating / emulating TCP

Brian Carpenter: It would be nice if we had a draft on this.

Brian Carpenter: Erik is correct - the only case where things look strange is where the flow-id is exported in a coarse-grained style. Multiple TCP sessions using the same flow-id will cause all TCP sessions to suffer the same mh fate

Christian Huitema: incremental deployment. In all the proposals you have to assume a world in which IPv6 is already deployed. The m6 proposal is an add on to a deployed network. You need an immediate benefit to yourself without requiring other sites to also upgrade. i.e. one-armed mechanisms that require no change to the other end. e.g. advertise >1 addresses in the DNS and let the other end choose. Want to see a way to solve egress filtering to an other end that cannot do the rewrite trick.

Tony Li: egress filtering is orthogonal to the rest of the issues here. They can be applied to all the proposals see so far

Dave Crocker: Rarely, I agree with Keith Moore. Need to distinguish between names as a name space and names as a query mechanism. MAST also has incremental adoption, but Huitema defined incremental adoption in a way that MAST is not. We don't have a common shared sense for criteria and terminology. Incremental deployment capability in not on criteria list. Other considerations emerging, and there is more. Theory is any single proposal may be attack on these criteria. We need to get clear what is important and what is not to allow proponents to respond carefully.

Kurt Lindquist: The RFC lacks criteria - the WG's evaluation list appears to be bigger than that listed in the RFC..

Brian Carpenter: This is an OPS working group - these are close to operational questions.

Crocker: I hear what you said but don't understand it.

Elwyn Davies: Wondering if we are transferring the problem from the data to the control plane. Bootstrapping is a real issue here. It needs to be thought through.

Matsataka Ohta: I propose that all proposals should address issues already contained in additional to the RFC careful analysis of interaction with DNS. For example in NOID DNS appears, but nothing is mention of DNS as a connectionless protocol using UDP. Section about connectionless UDP is very strange. ok?

Keith Moore: coming up with more criteria in a solution - this is good. But if you acknowledge that you are going to compromise in selecting than you will need a lot of help in doing the compromising. The discussion flows around renumbering, mobility, etc, and there is a good chance of conflicting with other efforts

Matsataka Ohta: General feeling about design parameters; global routing table size, number of prefixes. Can I have discussion?

Brian Carpenter: If we did not care about the number of prefixes we would not have this discussion

Randy Bush: (channeling Margaret Wasserman) Isn't there a multi6 draft about requirements? Shouldn't this draft be tuned with this discussion? What are the technical details of these proposals? The HIP BOF did a good effort of comparisons

Brian Carpenter: I feel a need for a document for a new set of considerations, need a volunteer for a draft

Sean McCleary: What is the expected number of per-host addresses in each proposal and what would push this number upward. Concerned that it may rise to several dozen - I am concerned if it gets to that high point

Tony Li: All the proposals are 1 locator per immediate ISP. Not 1 locator per inbound path

Eliot Lear: does it matter how many identifier there are?

[Several]: no!

Margaret Wasserman: I heard Randy channel me. The issues I have are referral (as per passive ftp) and simultaneous TCP connect attempts from each end. Questions about NOID from this perspective. In NOID when if A -> B and B -> A starts up at the same time, state on A with flow ID requires 2 DNS lookups on B and the B -> A connect attempt will be rejected in the meantime. Is this bad?

Erik Nordmark: this was an exercise left to the reader. The document has not thought through this scenario in detail. The document talks about state loss and re-establishment efforts. There is a risk of ending up with 2 different contexts. It sounds like the same issue, but not sure.

Margaret Wasserman: Have a problem when we completely separate the locators as an ID. How do we know this has occurred. Do we always do the 2 DNS lookups on a referral, or is there state.

Erik Nordmark: 2 reasons why this would not work. a) renumbering (long time scale) b) short term (routing). a) deal with it - don't keep these things around forever. Use the FQDN to consult the DNS. A locator without the FQDN is pretty useless. And the DNS reverse should fail in such a case. Referrals and failure simultaneous - you can pass across the id. One approach is the other end to do the 2 DNS thing to retrieve the full set of locators, or the other end could send off the full locator pool

Margaret Wasserman: does with work with 2-faced DNS?

Erik Nordmark: DNS inconsistencies in responses require you to come to the minimum intersection of the two sets. I've been thinking of a weaker mechanism with some sort of security and some sort of local or global scope.

Brian Carpenter: reverse tree reliance?

Christian Huitema: This is not a good idea. A cyclic dependency is not what you want. Today's reverse is populated with poor data to a level of around 50%. Not a good idea to rely on this data.

Brian Carpenter: multi-homed DNS server?

Randy Bush: MH is a lot of hoops. They will get reverse DNS right if its part of the necessary steps. The cyclic dependency is a substantive point.

Keith Moore: The rev-DNS tree is an anachronism. There are many forms of relationships in the reverse -> forward, and its not generally an inverse of the forward lookup functions

Dave Crocker: domain names are many things. Any global consistent name space requires a query service. Use a new one or a new one?

Randy Bush: put it in BGP!

Erik Nordmark: Careful not to create recursion here - need to be careful to use a lookup for locators not identifiers. DNS has its own way of doing that by listing the IP addresses of the name servers. You don't need to use this solution to lookup DNS name servers. I don't understand what the operational issues are. Its an identifier, not a locator. The DNS should check, because things will, just, fall apart. one more thing... mumble....

Matsataka Ohta: I don't want to change current operational practice. When its necessary use DNS reverse, but not mandate it. I actually proposed a way to use TCP options to pass locators which means DNS is not necessary.

Christian Huitema: The DNS is used to acquire a set of locators if you have a locator, and so conceptually you could ask a server, the other is to ask your peer. If you ask you peer to get an answer that is not dependant on a server

Erik Nordmark: the server is used as a verification to avoid certain forms of DOS attacks.

Christian Huitema: I hear you. The attack you describe was an attribute with mobile ipv6 - you do a 2 way handshake with the locator to verify before use, and this defends against he attack.

Erik Nordmark: You could this with an exchange - its something to go explore further

Randy Bush: what I think I heard from ohta-san the reverse is just increasing your confidence. The cert exchange is just increasing your confidence. But what's going to be different here?

Pekka Nikkander: We wanted to discuss the reverse DNS thing. A identifier / locator split will break things. A fix that relies on reverse DNS would be a little bit awkward.

Bruce Campbell: The DNS is distributed, but not reliable. Using DNS to load a mh session is not always reliable. This is an instance of middlebox attack

Perry Metgzer: True the DNS is not perfectly reliable, nor is IP. Things work without the DNS already, such as nutella. Its unfortunate that we are producing this hairy ball of interdependencies, but it may be the only way.

Steve Bellovin: ALIAS BOF about hints - hints are good for optimizations, but they are not reliable directives. As long as it still works if you can't get to the DNS this is better.

Iljitsch van Beijnum: We've looking into the DNS for locators or exchange. Another is to just go ahead with TCP and back off into another address on failure, and only on failure. i.e. backoff into this form of exchange

Christian Huitema: Privacy, and where to engage this mechanism. Many of the slides think of IP security as a layer above the exchange of locators, yet I can see why want to have a peer discussion but not want intermediaries to know of this. If we do an exchange to move traffic to other locators I'd like to do this with privacy. On the one hand you want to keep the IPSEC session going but protect the information about locators.

Dave Crocker: layering shown usage, not control channel

Keith Moore: Opposed to Perry's comment. Applications that do not depend on the DNS exist - many of them. The generalization is incorrect, and applications are a broad spectrum, not two types generically.

Brian Carpenter: No consensus about the use of reverse DNS in these approaches so far.

Margaret Wasserman: Use identifier or id rather weakly here. IP addresses are used within hosts as well as externally

Erik Nordmark: Christian Huitema suggested control channel privacy - this is a trade- off. I don't know if confidentiality for the control channel is necessarily the right thing to do.

Perry Metzger: This may not add up to better security overall. Architecturally - You need to name state. It can't be IP addresses. DNS labels are a fixed point and work as a named state.

Christian Huitema: the point is that we shall not impose a position on the trade- off on privacy. It should be clear that the solution should not _mandate_ that you drop confidentiality. I should have control of what I choose to disclose and this should be compatible with the solution.

Erik Nordmark: I understand the mobility concern about disclosure of location. This may be different between disclosure of mh state per se. After all any connection discloses the current connection state in any case.

Brian Carpenter: In a paranoid location you may deliberately move the location to take this to a non-disclosed locator.

Margaret Wasserman: Why fragment over NOID?

Erik Nordmark: Not NOID, thats SIM.

Margaret Wasserman: Why should it be above SIM?

Nordmark: The reason you have this flexible system you have the potential risk that different frags do down different paths. If reassembly is done BEFORE source rewrite then reassembly is not possible.

Brian Carpenter: Bound said - SCTP-based draft on the table. Anyone willing to get a HIP-based draft on the table?

Pekka Nikkander: This is an initial draft on this. I'm willing to work on a draft on this as a more specific effort.

Brian Carpenter: Need a draft summarizing the criteria we've discussed here.

Eliot Lear: I volunteer to write this up

Brian Carpenter: Each proposal should self-assess against criteria, as opposed to WG assessment.

Brian Carpenter: 31 Dec did not get WG approval, but a rush of proposal 2 weeks prior to next IETF is also tough. 'sometime in January" is a strongly preferred option.

Brian Carpenter: Need to think about how to converge ('marry') proposals into a WG proposal from a set of individual proposals.

Tony Li: A competition among proposals is a barrier to consensus and rational choice. We should be working in problems and look at salient features, solutions to each of those problems. They may not be in dependant, but thats fine. 'your' vs 'mine' is destructive to working together.

Erik Nordmark: What are the pieces: filtering and the right exist. Hints from elements need more work. It may not be a fine cut, but it has promise.

Brian Carpenter: maybe we can see similar components in each of the solutions

Kurt Lindquist: the security analysis looks common

Matsataka Ohta: We need proposals of complete architectures.

Brian Carpenter: we are not quite ready to do that yet.

Dave Crocker: Working over IPv4 as well could be considered

Brian Carpenter: Next Steps: Eliot Lear to prepare a draft on criteria analysis, Jim Bound a SCTP document,Pekka Nikkander to prepare a HIP-based document, i-d publication of design team document, complete gathering of ideas, prepare evaluation criteria as applied to proposals, and then undertake functionality analysis with a view to convergence of WG efforts.

Randy Bush [AD mode]: lots of real engineers in the room, too. We're opening a taboo can of worms successfully for the first time in a long time.

WG session adjourned.

Slides

Agenda
Dual-Homing Support for Single-Link Sites
multi6 design team #1 status update
MultiAddressing
MAST and Multi6
TCP Multi-Home Options
IPv6 Address Assignment and Route Selection for End-to-End Multihoming
LIN6: A Solution to Multi-Homing and Mobility in IPv6
Multi6 Threats
Multiple Multi6 Approaches
Next steps and discussion