Multi6 Working Group - IETF 58

Session 1
Tuesday 11 November

Agenda:

Session 2
Wednesday 12 November

Agenda:

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

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

Analysis

Dave Crocker

MAST

Dave Crocker

TCP Multi-Home Option

Arifumi Matsumoto

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

Source-Based Routing

Kenji Ohira

Lin6

Masahiro Ishiyama

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

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.