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
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
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
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?
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
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
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
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
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
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
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
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
Brian Carpenter: maybe we can see similar components in each of the
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