Subject: Minutes from the multi6 WG at IETF59

From: Kurt Erik Lindqvist <[email-masked]>
Date: Thu, 4 Mar 2004 05:44:18 +0100

Thanks to Marcelo for taking the minutes!!!

- - kurtis -

Multi6 working group
====================

Wednesday 3 March

Agenda:

     1. Agenda bashing and Administrativia, chair

     2. Charter review, chair

     3. Short intros to NEW drafts
        draft-ohta-multi6-threats-00.txt, Masataka Ohta
        draft-ohta-multi6-8plus8-00.txt , Masataka Ohta
        draft-ohira-multi6-multilink-auto-prefix-assign-00.txt, Kenji  
Ohira
        draft-arifumi-multi6-tlc-fm-00.txt, Arifumi Matsumoto
        draft-ylitalo-multi6-wimp-00.txt, Vessa Torvinen
        draft-nikander-multi6-hip-00.txt, Pekka Nikander
        draft-coene-multi6-sctp-00.txt, Lode Coene
        draft-crocker-celp-00.txt, Avri Doria
        draft-toyama-multi6-operational-site-multihoming-00, K. Toyama

     4. draft-lear-multi6-things-to-think-about-00.txt, Eliot Lear

     5. Architectural analysis, Geoff Huston

     6. Other issues

1. Agenda bashing and Administrativia
=====================================

     Brian Carpenter is not here today, so only Kurt Erik Lindqvist
     will chair the session.

     Session is broadcasted.

     Comments on the updated charter by Kurt Erik Lindqvist.
     Some modifications have been proposed to the charter. The updated
     charter has been sent to the IESG. The IESG then made some comments
     and those are being solved.
     There are new milestones, including:
     - Architectural evaluation for Feb. 04, which is expected to be  
based
       in the work done by Geoff Huston. April timeframe was considered.
       This draft will be used then to classify and evaluate proposals.
     - Informational draft about current multihoming practices in IPv4,
       as confirmed in the Vienna meeting. A draft exist covering this
       issue, but is to be updated. No much feedback about the draft yet.
       The chairs may need to find an editor for this.
     - Operational draft containing practical questions. The proposal is
       to base it on draft-lear-multi6-things-to-think-about-00.txt by
       Elliot Lear. The proposal is to obtain more discussion on this and
       then send it to last call.
     - Threats draft. The proposal is to base it on
        draft-nordmark-multi6-threats-00.txt.

     Questions:

     Pekka Savola: I am concerned about ID about current IPv4 multihoming
     today, there are still big issues with it. Is it already submitted?

     Kurt Erik Lindqvist: It has not been submitted yet, the chairs need
     to decide how to move forward with this.

Decisions/Outcomes
==================

1. Adopted draft-lear-multi6-things-to-think-about-00.txt as a working
    group item.

2. Geoff Huston will produce a draft containing the architectural
    analysis.

3. Erik Nordmark will update the security threats draft

4. Possible interim meeting to be defined.

00 Draft Presentations
======================

Threats Relating to Transport Layer Protocols Handling Multiple  
Addresses
- ------------------------------------------------------------------------ 
- -

     Masataka Ohta
     Multiple addresses assigned to homes in multihomed sites are needed
     in order to preserve global BGP routing table small.
     A session is something that needs state, so it is not at the IP  
layer,
     since no per connection state exists in IP.
     The connection state resides at the transport layer.
     So, this draft analyses the threats in transport layers managing
     multiple addresses.
     Threats:
     - Connection hijacking: it is not a new threat, since MITM in DNS
       queries/replies or rewriting an URL in HTTP can cause similar
       effects. The solution for this is to protect
       with cookies and this solution is already considered.
     - DDOS: The problem is amplification, This is not new threat, since
       it is similar to, for instance, what happens in the DNS, where the
       reply is longer than query.
       A multihoming solution should not generate answers that are longer
       than requests. However, new DOS opportunity can be caused by the
       usage of public key crypto in multihoming solutions, because  
public
       key crypto is costly. Cookie based solutions are not so expensive.
     - Privacy in the identification: A multihoming solution should allow
       to hide the identity information, so it should be allowed
       identifiers to be temporal.

8+8 Addressing for IPv6 End to End Multihoming
- ----------------------------------------------

     Masataka Ohta
     8+8 addresses is an old concept, and it is based are composed by 8
     bytes locators (used for routing) and 8 bytes identifiers (used for
     identification). For multihoming support with multiple addresses,  
the
     support cannot be provided by the IP layer, because IP is stateless.
     This proposal does not change IP.
     8+8 addresses the issue of interoperability with legacy hosts. For
     this it is necessary to discover when to use 8+8 capabilities i.e.
     whether the other end of the communication supports 8+8.
     The proposed solution is to use the group bit in the identifier to
     signal if the the node supports 8+8 mode.

     Question:
     ??: Are you proposing to use the group bit for this?
     Masataka Ohta: this bit it is not used today.

     Continue with presentation:
     A problem is how to distribute identifiers, in this case identifiers
     can be assigned like DNS names, since you can base the identifiers  
in
     the locators.
     Locator selection is not a problem because the global routing table
     is used for that.
     Source locator is not an issue, since source address is ignored.
     In the case that some issues related with ingress filtering
     compatibility appear, they can be solved through a modification in  
the
     IGP (such as OSPF modification).
     There are no problems with Mobility.
     The solutions proposes to modify TCP, but in a fashion that it is
     compatible with old TCP.
     The solutions presents all the desirable properties presented in
     RFC 3582.

Hierarchical IPv6 Subnet ID Autoconfiguration for Multi-Address Model...
- ------------------------------------------------------------------------

     K. Ohira
     Multiaddresses is proposed in several solutions
     This solution proposes an address assignment protocol to assign
     multiple addresses to host in multi-link multihomed sites.
     It is assumed that source address based routing will be used to  
select
     the exit.
     Transport survival is out of scope.
     The protocol proposed to assign addresses is the following:
      - Assign subnet identities to each link, by dividing the subnet  
field
        in the IP address
      - The top level router i.e. the one connection to the ISP, obtains
        a /48, and splits it downwards.
     RFC 3582 assessment slide

TLC-FM : Transport Layer Common Framework for Multihoming
- ---------------------------------------------------------

     Arifumi Matsumoto
     Fate sharing based classification of different type of solutions:
     - SCTP, TCP-MH and DCCP: each layer has its own multihoming
       information which is not shared with other transport layers.
     - Wedge solutions: the multihoming information affects all the
       sessions in the host. The problem with this approach is that each
       application cannot choose its own paths
     TLC-FM proposes to use an intermediate level of fate sharing
     (information shared). Each transport shares the information with
     other transport layers.
     However, each transport chooses the path for its packets, and it  
also
     is responsible to detect outages in the currently used path.
     The information that is shared is the path information, where a path
     is defined as a destination address, a source address and a next  
hop.
     Next hop information is especially relevant for multilink hosts .  
The
     information about the quality of the path should also be shared
     because it is useful when selecting a path to avoid network  
failures.
     Failure detection is performed by each transport using different
     mechanisms:
     - TCP: data retransmission
     - UDP: received ICMP messages (Destination unreachable, Time  
exceeded)
            and it can also use some help from applications (requiring a
            new API to notify outages)
     TLC-FM needs a control channel to inform about the addresses  
available.

     Questions:
     Pekka Nikander: It is an interesting proposal. Isn't similar to  
CELP?
     Perhaps it should be joined with CELP?
     Arifumi Matsumoto: It is similar to CELP. The difference is the  
policy
     since each transport can have a different path.

     Erik Nordmark: How do you apply this to SCTP considering that SCTP
     test its own path? You probably want to share the path test
     information too for performance benefits.
     Arifumi Matsumoto: The problem is that such feature is not available
     in other protocols.

Weak Identifier Multihoming Protocol (WIMP)
- -------------------------------------------

     V. Torvinen
     The basic assumption is that there are lighter operations than  
public
     key crypto.
     The basic operations are much faster.
     WIMP has two main components: a context establishment phase and a
     readdressing protocol.
     WIMP uses non routable endpoint identifiers. Identifiers are hashes
     of strings (fqdn,and ephemeral identifiers). The reason for that is
     not to allow the attacker to steal the identifier.
     Basic cryptographic concepts used:
     - Hash chains: recursive calculation of hash starting from a random
     number and then feeding the next hash with the output of the  
previous
     hash. The main characteristic of this chain of values is that it is
     impossible to know the next value from the previous one, but you can
     verify the previous value.
     - Secret splitting: it is used to send parts of the spit secret
     through multiple paths, assuming that no one attacker can intercept
     all the paths during a readdressing operation.
     Basic operation: 4 way handshake is used to establish context. The
     anchor values of the initiator and responder hash chains are  
exchanged
     during this handshake. It is vulnerable to MITM attacks at the  
initial
     exchange.
     Major comments received are about endpoint identifiers and flow
     identifiers.

     Questions:
     Elliot Lear: This looks similar to Purpose Build Keys? Is it  
similar?
     Pekka Nikander: The goal is the same, but WIMP uses hash operations
     instead of public key crypto, which provides same functionality with
     better performance
     Masataka Ohta: Sequence numbers can also be hashed with a key and it
     is just as good, and why do you split keys?
     V. Torvinen: We split the secret to make return routability to the
     new addresses.
     Masataka Ohta: This can be easily snooped.
     Erik Nordmark: Return Routability test is used to verify that the  
end
     is at the address that it is claiming.
     Margaret Wasserman: Good draft, but about secret splitting usage, it
     seems that you have to reach the host at the previous address, what
     happens when the host is no longer available at the previous  
address?
     V. Torvinen: We haven't considered mobility. In the considered case,
     the initiator informs about the locators he wants to use.
     Pekka Nikander: Just to clarify about this, there are two options
     here. One is to run the address exchange protocol before loosing the
     path, so when the path is gone there are no problems. The other  
option
     is to split the secret in such a way that it is good enough to  
obtain
     only some of the parts of the secret.
     Margaret Wasserman: How fragmentation and PMTU discovery are  
handled?
     More comments on the list.

Lightweight hip with delayed setup
- ----------------------------------

     Pekka Nikander
     The biggest criticism received when trying to apply HIP to  
multihoming
     is that hip is too heavy.
     HIP in opportunistic mode provides protection against everything but
     initial MITM attack.
     The proposal is to preserve current level of security with less  
cost,
     by combining WIMP and HIP.
     The idea is to combine initial 4-way exchange of HIP and WIMP, so  
that
     initial messages carry both HITs and MAC of the anchors.
     The receiver then can choose to use HIP or WIMP. So the  
communicating
     nodes can continue to use WIMP as long as they want, but they feel
     that they are facing an attack you, then they can run full HIP to
     protect themselves.
     Still more in depth analysis of the potential introduced
     vulnerabilities is required.

     Questions:
     Richard Graveman: IKEv2 provides same features and also protects  
from
     initial MITM
     Pekka Nikander: You need PKI to protect initial MITM, since in
     opportunistic mode you can't protect initial MITM attack.
     ??: do you use IPSec in light mode?
     Pekka Nikander: no.

Multihoming: the SCTP solution
- ------------------------------

      L. Coene
      This draft essentially asses the SCTP multihoming solution with
      draft-lear-multi6-things-to-think-about-00.txt
      - No rendez vous for mobility are considered, since SCTP only
        performs the handover.
      - No additional latency, because data and control traffic are
        transmitted together.
      - No problems with DNS since it is only used to get an initial
        address.
      - For authentication: the proposal is to use PBK, and it seems that
        it will work.
      - How does the host knows its own ids? SCTP tries a subset of the  
IP
        addresses assigned to the host.
      - No extra load for DNS.
      - No extra upstream ISP support required.
      - The solution impact on the different sizes of sites from SCTP
        perspective is none since, SCTP doesn't care about the amount
        of addresses being handled.
      - About referrals:

      Question:
      Elliot Lear: the referral point is related to applications like  
FTP.
      Margaret Wasserman: Referral is not only about A telling B how to
      contact C, but also about A telling B how to contact A two hours
      later.
      L. Coene: I will review the referral aspects.

      Continue with the presentation:
      - No application changes are required
      - IP issues are solved in Christian's draft

      Questions:
      Margaret Wasserman: how does the draft addresses the point included
      in the goals draft?
      L. Coene: I forgot to include these points.
      MW: the goals draft require TCP and UDP support, how do you deal
      with that?
      LC: It is not supported
      Kurt Erik Lindqvist: RFC 3582 is a goals document, not a  
requirement
      document.

      Continue with presentation:
      Conclusions:
      - Some applications may be migrated to SCTP.
      - Reports about ADDIP messages in next meetings.
      - Deploy SCTP in carrier networks with multihoming support.
      - There is some work going on about multipath.

      Questions:
      Erik Nordmark: Is there some experience about selecting locator and
      paths available?
      LC: We are trying to collect the information. If IP is not working
      properly, there are problems. We are trying to collect more
      information about this.

Framework for Common Endpoint Locator Pools
- -------------------------------------------

     Avri Doria
     There are multiple multiaddressing schemes, so we are looking for
     commonalities between them, so that they can share the work done by
     the other mechanisms available in a host, sort of an opportunistic  
use
     of other's information. The goal is to reduce transaction cost.
     There are two types of schemes identified : transport approaches and
     wedge approaches. Each approach has its benefits, but not all them
     solve all the problems.
     The proposed approach is to create common locator pools, so that  
both
     transport and wedge solutions can contribute to it.
     Different granularities are proposed for the stored information:  
host,
     flows, protocols, ToS
     The next step is to look at each multiaddress solution to see what
     they can provide.
     Each solution can insert information into the pool, and also benefit
     from the information available in it.
     There are several issues but the idea is to start with a simplified
     mechanisms and then go to more complex solutions.
     There are also some security issue related with how do manage when
     multiple solutions with different levels of security insert
     information into the pool.
     Other issues related to names used to identify locators pools.
     The next steps are: resolve the security and naming issues above.
     Go through other proposals, as stated earlier. Identify near term
     issues and longer term issues.
     All proposals have value and probably many of them will de accepted.

     Questions:
     M. Ohta: Different protocols have different ideas about the
     availability of paths, retransmission times and so on. Since this
     information is protocol independent, so you cannot share the
     information.

     AD: Different attributes for different pools can characterize that,
     and the administration of the pool is complex, so that for each
     protocol you need specific information.

     M.O.: But if you make it protocol wise, you don't have shared
     information then.

     Kurt Erik Lindqvist: Take it to the list.

Operational Approach to achieve IPv6 multihomed network
- -------------------------------------------------------

     K. Toyama
     In IPv6, it is assumed that only aggregated routes will be  
advertised
     globally.
     This is a routing based solution, wihtout affecting the global
     routing table.
     It is proposed that a /32 and an AS number is assigned to the
     multihomed costumers of a group of ISPs, and that a /48 of this /32
     assigned to each multihomed site.
     Peering relationships are established between the involved ISPs that
     serve the multihomed clients, so that each ISP injects the complete
     aggregate to the Internet.
     So the ISPs cooperate.
     The request is to allow the allocation of the resources required by
     the solution.

     Questions:
     Erik Nordmark: what happens if one of the ISPs goes down completely?
     K.T.: The other one provides backup.
     Elliot Lear: this solution can be implemented wihtout changes, but
     have you talked to ISPs about how do they feel about implementing
     this?
     K.T.: Not all pair of ISPs will want to cooperate.
     Francis Dupont: I have published something similar a long time ago.
     Peter Lothberg: There is not a single cloud which is the global
     Internet.

End of 00 presentations
- -----------------------

Presentations about specific charter items
==========================================

Things MULTI6 Developers should think about
- -------------------------------------------

     Elliot Lear
     This is not a requirements document.
     It contains things beyond multi6 scope.
     It is not an architectural draft, it is about operational issues.
     It is not a position paper.
     It is a collection of operational questions, several of them are
     interrelated.
     For instance performance and security issues are considered in all
     the document.
     Key issues considered in the document:
     - Protocol on the wire: packet format changes introduced? and in
       which layer? Why that layer was selected? Impact on transport  
layer
       (pseudo header)?. Required changes on fragmentation? Additional
       latency? Are the changes required by all hosts or only multihomed
       hosts?
     - Security: How do you secure the binding between different names
       involved? Are there any new DOS opportunities created? Do you rely
       on other security infrastructure?
     - name/binding issues: Which is the lifetime of the binding? How is
       the binding updated? Do you introduce a new namespace? if yes,  
then,
       how does it looks like and how is it managed? Which is the  
relation
       with DNS?Is there any upstream ISP support required? Are there any
       dependencies on middle boxes? if yes, then what if they fail?
     - If the DNS is used: are there any circular dependencies between  
DNS
       and the routing system. Are there any new RRs? Is the FQDN goes in
       every packet? How is two faced DNS supported?

     Question:
     Pekka Savola: circular dependencies are more general than only to  
the
     DNS.
     E.L.: Yes.

     Continue with presentation:
       How does a host knows its own identifiers? Does the solution place
       an additional load in the DNS? Is DNSSec performance an issue?
     - Application implications: is it a new interface required? How do  
you
       support referrals like ftp, sip?
     - Backward compatibility: How the solution works with old IPv6? Can
       old IPv6 devices benefit from the solution? Do non-multihomed  
sites
       have to make changes? Changes are required on hosts, routers,  
both?
       Are there any changes in the management model?
       Two tests are suggested: how do you implement your solution in an
       IETF conference network? Have you tried in a lab?
     - Legal stuff: Do you create a new mnemonic namespace? How do you
       manage it?
     The goal of the draft is to compare results between proposals,
     creating a matrix to compare results. Perhaps even to merge similar
     solutions.

     Question to the Working Group:
     How many people have read the draft? Many hands.
     Do you think it needs more detail?
     M. Wasserman: It should be a living document, since changes will be
     introduced in the future. One thing I like to see added, about have
     delayed setup. When I start talking, do I need to know if the other
     end supports the multihoming solution? Another issue is, do we know
     which are the right answers?
     E. Lear: We should determine the set of important questions.
     Kurt Erik Lindqvist: Application people input is required. Security
     issues are listed, so the idea is to list the goals for security in
     each proposal. We don't want the document to contain the answers of
     the questions, we leave this for later.
     Pekka Savola: Some issues should be expanded, like what are the
     critical things. Some of the answers for this questions provided by
     the solutions are missing the point, so perhaps we should clarify.
     M. Ohta: The draft is very good, the checksumming issue should be
     included.
     K. Lindqvist: This is one of the new charter items, so

     Question to the Working Group: Who wants this as a working group  
item?
     Many hand for yes and no hand for no.

An Architectural View of Multi6 proposals
- -----------------------------------------

     Geoff Huston
     Clarification: specific proposals are used just as examples.
     There is a very large amount of proposals and some look similar.
     The goal is to try to make a taxonomy based on the architectural
     goals of the proposals.
     Problem space is a multihomed site. Note that there may be more that
     two ISPs, and that communications don't only involve 2 parties  
always.
     Exit routers and hosts appear because they are included in several
     proposals.
     Presentations of the goals presented in RFC 3582 and some of the
     questions of Elliot's draft.
     There are three mayor approaches:
     - Wedge a new layer in the stack: Based on Soch's work (who, where  
and
       how) while in IP only the IP address is used for all of them.  
These
       proposals are trying to disambiguate the who from where and how.
     - Modify the stack, whether transport or IP
     - Modify the local interaction: Destination based forwarding  
algorithm
       is modified to select the right exit.
     Wedge solutions.
       Can be placed above IP or above the transport layers. Most  
proposal
       are below transport. ULP deal with an identity token and IP deals
       with locators. The hosts control the locators set but the ULP are
       not aware of the changes. There is an identity peering between the
       communicating hosts.
       There are many ways to do this:
         - Conventional: add a new OSI layer -> new header trailer,
           communication in band.
         - New control channel (out of band): can communicate even  
without
           data. It has its own triggers.
         - Refer to a third party, like the DNS.
       While architecturally all are the same, there are changes in the
       implementation.
     Modification to existent layers.
       - Fatter transport: SCTP example where pools of locators managed  
by
         transport. A new transport is needed.
       - Modified IP: One IP address is an alias for identity and the  
other
         IP address is an alias for location.
     Modified host/router interaction
       - Doesn't fit the layer model nicely.
       - The problem solved is that when a source address is selected and
         the wrong ISP is used, the packet is discarded
       - This means that when selection the source address implies a
         topological decision.
     IPv4 multihoming style: not an option?
     Common issues identified:
       - Required locator selection mechanisms by the host.
           - One's source locator is the other's destination, so this
             selection imposes the reverse path.
           - How is the selection among different destination locators?
           - How do you change locators once that the selection is made?
             when a change is needed? how are network failure detected?
     Some examples of analysis for proposals:
       - HIP: Shim layer between transport and IP. A stable identifier is
         presented to transport layer. Multiple locators are bound to a
         fixed identifier. So, locators can change in a session.
       - SIM, NOID and CB64: Shim layer approaches. NOID is referential,
         SIM uses protocol exchanges and CB64 is hybrid. Additional
         elements since exit router rewrite packets
     About namespace structure:
       - Hierarchical
          -Identifiers are part of the IP address space.
          - FQDN are used. Problems with the interaction between DNS and
            routing. The DNS may not be good enough for this mapping
          - New token: why is it needed? what feature is not available in
            existent namespaces?
       - Opportunistic: no need to manage the name space. How referrals  
are
         handled?, How searches are performed?
     SCTP: Heartbeat required to trigger locator change
     MIPv6: Only one locator valid in a give moment, encapsulation  
carrying
     the locator in the outer header and identifier in the inner header
     Modified host/site-exit interaction: Site forwarding paradigm is
     changed. Multiple options, like anycast address, source address  
based
     forwarding, source address rewriting.
     Other option is to provide a solution for the initial problem which
     is ingress filtering, so just release ingress filtering.
     Common issues:
     - How do you select best source locator?
     - How do you select the best destination locator?
     Detecting network failure
       - Heartbeats
       - Transport
       - ICMP from router
       - Note that failure between startup and once the session is
         established
     Security is not in the scope of this work, worthy of a separate
     analysis

     Questions:
     Erik Nordmark: The approaches that change the host/router relation,
     make the edge more explicit?
     G.H.: Yes, perhaps reality is not like this.
     E.N.: Are there any other architectural implications with making  
this
     border explicit?
     G.H.: If this model is mapped to reality, do you have a clean idea  
of
     what the exit is?
     M. Wasserman: what is the process in order to move more into details
     from here?
     Kurt Erik Lindqvist: Doing a document about proposals doing an
     evaluation referred to this taxonomy, and classify the proposals
     according to this. Besides with Elliot's draft we could have a
     benchmarking of the proposals.
     M.W.: I am worried that the architectural analysis is based on
     proposals, and that what is not covered by proposals is not included
     in the analysis.
     K.E.L.: Many proposals overlap, so we need to group them together
     Dave Crocker: Multihoming and mobility can be covered with similar
     mechanisms
     G.H.: I think the assumptions made by the solutions in both cases is
     that the identifier can be used as a glue between locators.
     D.C.: It may be complex if we try to solve all the problems in one
     and it may take forever. OTOH, separate solution may make things  
even
     more complex.
     Pekka Savola: A general comment: To progress we have to figure out
     deployment scenarios, and not only one solution will fit all the
     scenarios.
     K.E.L: Yes, that is why the document describing current IPv4
     multihoming solutions is needed.
     James Kempf: Define deployment scenarios and simulations to see how
     this work
     K.E.L.: last comments on how do we proceed. The assumption was that
     Geoff would write a document with the architectural analysis.
     Additionally, we have to move forward the threats draft. Perhaps an
     interim meeting is needed.