Subject: delayed multihoming/mobility set-up

From: Pekka Savola <[email-masked]>
Date: Fri, 14 Nov 2003 01:10:54 +0200 (EET)

Hi,

Me and Dave Crocker sat down and thought about multihoming and mobility a
bit.  Among other things, we came up with one notion which may not have been
explicitly mentioned, but may be relevant:

  Is it necessary to ensure connection survivability prior to the connection
  establishment?

  Or, is it necessary to ensure connection survivability in parallel with
  the connection establishment?

  Or even, is it OK to just ensure connection survivability only for
  "long-lived" sessions (e.g., those which have lasted for longer than 5
  minutes), using some definition.

The last one would be obviously useful with low-mobility rate, or site
multihoming when the connection survivability method you're using would
require extra packets or extra delay to set up -- and you'd want to avoid
that when it's not necessary.

Note that in low-mobility or site multihoming scenarios you don't expect
the the multihoming to be required *immediately*; the risk increases in
proportion to the time.  Would an "intentional race-condition" be
acceptable in most cases?

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 14 Nov 2003 20:16:27 +0900

Pekka Savola;

>   Is it necessary to ensure connection survivability prior to the connection

Survivability of what?

Nonexisting connection?

If the attempt of establishment fails for some reason, there can
be no survivability.

Abortion is leagal, here.

>   the connection establishment?

Because of race conditions, it does not ensure anything.

A conservative leagal request is to ensure the (best effort)
survivability at birth, which requires piggy backing and minimal
(3way) handshaking, which means there is no race.

>   minutes), using some definition.

There is no proper timeout value at the IP layer.
 
> that when it's not necessary.

You are trying to import "connection" at the IP layer, in vain.

"low-mobility" is rather a link layer issue.

							Masataka Ohta

---

From: Pekka Savola <[email-masked]>
Date: Fri, 14 Nov 2003 15:41:31 +0200 (EET)

> Because of race conditions, it does not ensure anything.

Did I suggest it would *ensure* it?

But if the probability of a multihoming related problem increases in 
proportion to the time passed for a connection/flow-of-packets, what this 
is doing:

 - optimizing away multihoming overhead when it isn't necessary (i.e., by 
the definition of user, that is, the triggers it uses, when it feels that 
the multihoming benefits outweigh its setup costs)

 - still giving a possibility to get the multihoming benefits when the 
user feels they're useful/required, with no overhead with the rest.

> There is no proper timeout value at the IP layer.

Right, but with IPv6, there is flow label.

---

From: Dave Crocker <[email-masked]>
Date: Fri, 14 Nov 2003 15:09:04 -0600

Folks,

PS>   Is it necessary to ensure connection survivability prior to the connection
PS>   establishment?
PS>   Or, is it necessary to ensure connection survivability in parallel with
PS>   the connection establishment?
PS>   Or even, is it OK to just ensure connection survivability only for
PS>   "long-lived" sessions (e.g., those which have lasted for longer than 5
PS>   minutes), using some definition.

By way of saying the same as the above, but using other words:

The different multiaddressing proposals have very different service
models, in terms of their ability to assure that a connection is
maintained across different locator usage.

If the multiaddressing negotiation precedes connection establishment,
then connection survival is possible for the entire life of the
connection.

If the negotiation is done in parallel with the start of the regular
transport connection, the the early period of the connection will not
survive a change in locator.

If the negotiation is deferred until much later in the life of the
connection, obviously the connection is vulnerable beforehand, but all
of the overhead of the negotiation is avoided for short-lived
connections.

The question, then, is how important people believe this range of
choice and range of service is.

d/
--
 Dave Crocker <dcrocker-at-brandenburg-dot-com>
 Brandenburg InternetWorking <www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Mon, 17 Nov 2003 21:26:56 +0100

> acceptable in most cases?

If we assume that we are using BGP for the EGP routing updates, we have 
the Ahuja/Labovitz route cancellation effect. If I remember correctly, 
their research showed that 40% of re-routing takes 2-4 minutes (I am 
taking this out of my head). This would IMHO give the reference of how 
long a "rehoming event" could take. Anything lower than that is a bonus 
:-)

- - kurtis -

---

From: Pekka Savola <[email-masked]>
Date: Mon, 17 Nov 2003 22:43:13 +0200 (EET)

On Mon, 17 Nov 2003, Kurt Erik Lindqvist wrote:
[...]
> long a "rehoming event" could take. Anything lower than that is a bonus 

Uhh, could you clarify how this relates to this subject?  I think I see a 
few ways to tie these together, but I'm not sure what your point is..

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Mon, 17 Nov 2003 21:58:38 +0100

> few ways to tie these together, but I'm not sure what your point is..

( I was a bit fast there, to much mail to read and catch up with)

Well the point I was after was your discussion on when a connected 
session should expect connection survivability. In todays IPv4/IPv6 
internet, a connection passing over a EGP boundary (and I guess in 
worst case even inside ASes) will have to take the route cancellation 
in effect. This means that you will always have to worry about this. So 
the last you said was :

> proportion to the time.

And I was pointing out that you can't expect it to be immediate in the 
case above.

Does this make any more sense? :-)

- - kurtis -

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 18 Nov 2003 08:14:50 +0900

Kurt;
 
> taking this out of my head).

That is a reason why global routing table should be shrinked.

> This would IMHO give the reference of how 

It is not the reference for M6 as the proper timing is application
dependent.

It, instead, is the reference for BGP++.

							Masataka Ohta

---

From: Pekka Savola <[email-masked]>
Date: Tue, 18 Nov 2003 22:21:21 +0200 (EET)

On Mon, 17 Nov 2003, Kurt Erik Lindqvist wrote:
> > Uhh, could you clarify how this relates to this subject?  I think
> > I see a few ways to tie these together, but I'm not sure what your
> > point is..
> 
> worst case even inside ASes) will have to take the route
> cancellation in effect. This means that you will always have to
> worry about this. So the last you said was :
> 
> > Note that in low-mobility or site multihoming scenarios you don't
> > expect the the multihoming to be required *immediately*; the risk
> > increases in proportion to the time.
> 

No, this does not make sense.

I'm trying to guess what point you're making.  I can see two 
possibilities which neither clearly falls inside your text:

 1) "if a route goes down, how long does it take to be able switch to 
the other connection if the protocols supported transport 
survivability"

 2) "if a route goes down, and comes back up, how long does it take 
until it's fully usable everywhere?"

Both of these are interesting, but not directly related to the 
question I raised, AFAICS.

Could you try to elaborate a bit more?

The proposal was all about stable configuration.  Instead of setting
up connection survability immediately when setting up the connection,
it would only be done for connections that pass certain criteria check
(e.g. last more than T minutes).  That way, if there is a failure
inside 0 ... T minutes from the startup of the connection, the
connection in question will fail.  If not, it'll just switch to the
another connection transparently, with the possible problems switching
connections may have.  This is just about optimizing away the
connection survability for "statistically" short-lived sessions unless
you really care about that feature.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 19 Nov 2003 14:51:28 +0100

What we should probably be clear about is that multi6
is not aiming to support instant QOS restoration. In other words
we are not aiming to be qualified for emergency services and not
even for fast signalling (which is what SCTP is aimed at).

   Brian

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter 
Distinguished Engineer, Internet Standards & Technology, IBM 

NEW ADDRESS <[email-masked]> PLEASE UPDATE ADDRESS BOOK

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Mon, 24 Nov 2003 21:43:49 +0100

> until it's fully usable everywhere?"

I was aiming for statement #2 here.

> question I raised, AFAICS.

Maybe I didn't understand your original question correct then.

> you really care about that feature.

My point was that in order to determine what a useful "timeout" value 
would be, it has to be longer than the risk of cancellation - depending 
on where in the network you are and what type of sessions we are 
talking about. If T is to low, once you think you have a stable route, 
it might get cancelled. Is this important for end-nodes? Not 
necessarily. If the nodes gets a locator assigned to it - it might.

- - kurtis -

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Mon, 24 Nov 2003 22:11:19 +0100

What I think we need to do at some point in the future though, is to 
define what we _can_ do. Agreed, that is far way and not what we should 
focus on now.

- - kurtis -

On onsdag, nov 19, 2003, at 14:51 Europe/Stockholm, Brian E Carpenter

---

From: Geoff Huston <[email-masked]>
Date: Tue, 25 Nov 2003 17:13:48 +1100

Multi6 Working Group
--------------------

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 NONE 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 dependant 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 packets
   - 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 NDS in 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
==================

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

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

   Ellwyn Davis: Wondering is we are transferring the problem from the
     data to the control plane. Bootstrapping is a real issue here. It
     need 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 frag over NOID?

   Erik Nordmark: Not NOID, thats SIM.

   Margaret Wasserman: why should it be above?

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

WG session adjourned.

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Tue, 25 Nov 2003 07:29:30 +0100

Thanks!

- - kurtis -

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 25 Nov 2003 11:10:23 +0100

On 18-nov-03, at 0:14, Masataka Ohta wrote:

>> If we assume that we are using BGP for the EGP routing updates, we 
>> have the Ahuja/Labovitz route cancellation effect. If I remember 
>> correctly, their research showed that 40% of re-routing takes 2-4 
>> minutes (I am taking this out of my head).

> That is a reason why global routing table should be shrinked.

I'm afraid these two issues aren't really related. The reason that BGP 
rerouting can take so long is that the RFC mandates a 90 second hold 
time, but Cisco and presumably others use an even longer default hold 
time of 180 seconds. Operators are often reluctant to change the 
default.

Once the BGP session goes down there is of course the issue of updating 
all the related routes, which can also take some time depending on the 
number of routes that ran over the neighbor. But this is usually a 
matter of seconds (think a one digit number).

> It, instead, is the reference for BGP++.

We already have BGP4+, but now we need BGP++?

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 25 Nov 2003 12:43:02 +0100

>   minutes), using some definition.

Ideally, it should be possible to take an identifier, connect to it and 
the connection establishes as long as there is a single working 
source/destination locator pair. However, if we want to build this, we 
need an identfier->locator (and probably also locator->identifier) 
mapping infrastructure. At present, nobody seems too thrilled about 
either using the DNS for this or building something from scratch. This 
approach also has the downside that it's all or nothing: both sides 
must implement it and the mapping infrastructure must be in place 
before it can work.

The alternative is making improvements to what we have now. One thing 
that needs to be solved regardless of what else happens is the whole 
source address/exit ISP selection and ingress filtering problem. 
Another problem that we can solve on just one end (which makes it 
infinitely easier to do) is establishing a connection in the presence 
of unreachable destination addresses. This is hardly rocket science, as 
very old versions of telnet and FTP already cycle through all IP 
addresses associated with a FQDN until they find a live one. Many IPv6 
applications do this quite well today (ie, not requiring a very long 
TCP connect timeout before trying another address). And on systems that 
provide a connectbyname() function call this entire problem can be 
solved in the OS rather than in individual applications.

The only thing that we can't possibly solve without involving both ends 
is connection survivability. Now obviously we can go back to our ideal 
solution as listed above, or we can add some stuff to existing 
protocols that makes it possible to repair reachability problems in a 
backward compatible manner. The huge advantage here is that there is no 
need to determine the type of connection that can be set up beforehand: 
just connect and see what happens.

The next step is setting up the multihoming mechanisms. Rather than 
exchanging addresses in-band, I think we should limit ourselves to just 
announcing an authentication token. This can easily be done with 
minimal overhead in a destination option in one of the first packets. 
Then the session (including non-TCP "sessions") can proceed as they 
would normally in the absense of multihoming mechanisms.

Only when the connection gets stuck because of a a reachability problem 
(and the session would normally time out), the multihoming stuff kicks 
in. If the session was set up using the DNS, the initiator or client 
knows the locator addresses for the other side so it is able to find a 
working source/destination locator set. If additional locators aren't 
available, then it is still possible to repair most failures by 
sticking to the destination locator but jumping to a new source 
locator. Obviously, there would have to be some serious negotiating as 
the other side doesn't know the packets with the new source addresses 
belong to the existing session. This is where the authentication token 
comes in, in order to prove that the "new" correspondent is the same as 
the previously known one.

To answer your initial question whether it is necessary to protect not 
yet established sessions using multihoming mechanisms: in the above 
universe this wouldn't be required as the application or OS on the 
initiating side knows how to connect to a correspondent with 
unreachable locators without employing end-to-end multihoming 
mechanisms. But it's probably useful to provide this functionality 
anyway if possible to accommodate applications that don't do this 
themselves or use system calls that allow the OS to do it.

One additional caveat if we go this route: since the additional 
locators aren't available until there is a reachability problem, smart 
upper layer protocols don't get to do their thing. I think this can be 
solved by adding additional mechanisms that ty in to the core session 
survivability mechanisms by allowing the ULP to request adding new 
locators to the mix. The multihoming layer then negotiates with the 
other side and then reports back to the ULP whether it can use the 
requested locators. After that, the ULP can bypass the rewriting that 
would normally be done by the mh layer and use its own magic. Note that 
the way this is done today in SCTP where the ULP negotiates the 
additional addresses itself is probably insecure.

---

From: Dave Crocker <[email-masked]>
Date: Tue, 25 Nov 2003 07:51:05 -0800

Iljitsch,

IvB>  The reason that BGP
IvB> rerouting can take so long is that the RFC mandates a 90 second hold 
IvB> time,

The reason that BGP has a long hold is because short times lead to route
flapping.

This is an inherent property of doing route calculations.  A scheme that
is too quick to change will be constantly changing.  Hence the
assessment of a particular route always needs to be pretty slow to
change the assessment.

That is why I think the way to achieve quick response is with a model of
parallel paths.  When one goes out, the other is already in use.  (Of
course, this introduces the costs of out-of-order packets.)

d/

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 25 Nov 2003 17:39:38 +0100

> The reason that BGP has a long hold is because short times lead to 

Hm, it shouldn't have to. And BGP has route flap dampening.

> assessment of a particular route always needs to be pretty slow to

I disagree. The right thing to do would be to popagate bad news fast, 
and good news slower. This limits the amount of flapping almost as well 
as delaying both good and bad news, while still allowing fast rerouting 
when failures happen.

Regardless, there is no reasonable scenario where a keepalive comes in 
after 179 seconds. Three minutes is just too long. In my book I 
recommend 15 seconds but this is probably a bit too agressive: 
unfortunately there seem to be some BGP implementations that fail to 
generate keepalives frequently when they're busy, so setting the 
keepalive to 15 seconds leads to frequent flaps. But 30 seconds should 
be ok most of the time, maybe 60 seconds for the conservative crowd.

> course, this introduces the costs of out-of-order packets.)

I'm not sure if this is worth the trouble for just failover. Remember 
that by using twice the paths you're also vulnerable to twice the 
outages. But we probably want this for load balancing anyway.

---

From: Geoff Huston <[email-masked]>
Date: Wed, 26 Nov 2003 07:55:47 +1100

>rerouting can take so long is that the RFC mandates a 90 second hold time, 
>but Cisco and presumably others use an even longer default hold time of 
>180 seconds. Operators are often reluctant to change the default.
>
>number of routes that ran over the neighbor. But this is usually a matter 
>of seconds (think a one digit number).
>

Iljtsch is of course right - its also useful to bear in mind that _any_ 
distance vector
algorithm takes time to propagate, and any distance vector algorithm that
needs to also synch itself with interior routing systems will take more time.

The trade-offs here is speed vs stability. BGP is biased towards stability as
that is the best path we know for scaleability. I'm not sure that BGPn for any
n>4 will break out of this need to strike a balance between these two 
attributes.

That being said, all this strikes me as wandering off into the weeds for this
topic! :-)

   Geoff