evaluation of draft-van-beijnum-multi6-odt-00.txt

[Iljitsch van Beijnum <iljitsch@muada.com>]

This is a short evaluation of the draft I submitted earlier today 
against RFC 3582 and draft-lear-multi6-things-to-think-about-00.txt.

(For those who can't wait: it's available at 
http://www.muada.com/drafts/draft-van-beijnum-multi6-odt-00.txt )

3.1.1 Redundancy

Well, duh.  :-)

3.1.2 Load sharing

Since the solution will generally only kick in when the initially 
chosen path no longer works, most load sharing depends on the initally 
chosen path. The protocol mandates interactions that show the 
characteristics of the new paths when those are negotiated so load 
sharing when the protocol is active should be reasonable. It is 
possible to support multiaddress transport protocols for really great 
load sharing.

3.1.3 Performance

See 3.1.2. This goal is only partially met.

3.1.4 Policy

Again, this mostly comes down to the initial choice.

3.1.5 Simplicity

I think this goal is met if no IPsec is used.

3.1.6 Transport survivability

Check.

3.1.7 Impact on DNS

Check.

3.1.8 Packet filtering

The current source address selection problem must be solved in order 
for sessions to be established in the first place. After that, the 
protocol will determine which address pairs work and which don't.

3.2.1 Scalability

Check.

3.2.2 Impact on routers

A new extension header must be parsed. Otherwise no impact.

3.2.3 Impact on hosts

ODT is completely backward compatible with current IPv6 and IPv4, 
assuming the presence of the extension header doesn't create any 
problems. The additional functionality can be implemented in the host 
kernel or a middlebox.

3.2.4 Host-routing interaction

None.

3.2.5 Operations and management

Operations and management might be slightly more difficult because 
traffic flow becomes less predictable and it becomes harder or even 
impossible to determine which packets are part of the same session by 
looking at packets on the wire.

3.2.6 Cooperation between transit providers

None needed.

3.2.7 Multiple solutions

Additional ways to enable the creation of new sessions when the 
initally chosen address is unreachable and especially better address 
selection (both source and destination) are highly desirable in 
addition to this solution.

4 Security considerations

Security was considered. When IPsec isn't used and an attacker can 
monitor the packet contents in the initial packets, the attacker can 
redirect traffic to addresses under her control. Whether this is a 
materially worse threat than threats that already exist on insecure 
links is debatable. The fact that data flows to/from unexpected 
addresses may violate site or application security policies.

2.1 Routing

Routing isn't affected as the solution just makes use of the routing 
infrastructure without interacting with it in novel ways.

2.1.2.1 Mobility

Mobility wasn't considered. However, this solution largely solves the 
same problem as mobility in a similar way. As such it would be strange 
to implement both on the same host.

2.2.1 Does your solution provide for a split between identifiers and
      locators?

That's one way to look at it, yes.

2.2.2 What is the lifetime of a binding from an identifier to a locator?

Indefinite.

2.2.3 How is the binding updated?

The multihoming sub-layer in the IP or transport layer initiates 
(re)negotiation of addresses when this is deemed appropriate.

   Will transport connections remain up?

Of course.

2.3.1 At what layer is your solution applied, and how?

Between the network and transport layers.

   Is it applied in every packet?  If so, what fields are used?

Yes. The address fields. For TCP and UDP, the checksum.

2.3.2 Why is the layer you chose the correct one?

Ask me again over beers some time.

2.3.3 Does your solution expand the size of an IP packet?

Only during the negotiation phase, sometimes.

2.3.4 Do you change the way fragmenting is handled?

No, except for middleboxes implementing the solution.

   If you use a shim approach, do you fragment above or below the shim?

The shim is applied after fragmentation as this is the only way to 
allow implementation in a middlebox.


2.3.5 Are there any changes to ICMP error semantics?

No.

2.4.1 Please explain the relationship of your solution to DNS

Nothing new here.

2.4.2 Please explain interactions with "2-faced" DNS

The DNS must supply at least one working address to the host initiating 
the communication. What it does or doesn't do apart from this is of no 
relevance.

2.4.3 Does your solution require centralized registration?

No.

2.4.4 Have you checked for DNS circular dependencies?
2.4.5 What if a DNS server itself is multihomed?

Since the solution only kicks in when single homed operation is no 
longer possible, by definition applying this solution doesn't do any 
harm. However, using ODT with DNS introduces additional dynamics where 
they aren't desired without much benefit so this is discouraged.

2.4.6 What application/API changes are needed?

Applications should try the full list of available addresses. See the 
draft for more information.

   Will old code just work with the new mechanism?

Yes.

2.4.7 Is this solution backward compatable with "old" IP version 6?

Yes.

   Does your solution impose requirements on non-multihomed/non-mobile
   hosts?

Single homed correspondents to multihomed hosts must implement the 
solution in order to achieve multihoming benefits for a session.

2.4.8 Is your solution backward compatable with IPv4?

Yes.

   How will your mechanism interact with 6to4 gateways and IPv4 hosts?

It should be transparent. Additionally, it should be possible to rehome 
IPv4 sessions over IPv6 and vice versa.

2.4.9 How will your solution interact with other middleboxes?

   What are the implications for firewalls?

Firewalls must be positioned such that all packets are seen by them. 
This is of course at odds with the redundancy requirement.

   What are the interactions with NAT?

It isn't entirely impossible that the solution works with some NATs 
some of the time. Minor provisions have been made to allow a single 
homed system behind a NAT to communicate with a multihomed system.

   What are the interactions with web caches?

Unknown.

2.4.10 Are there any implications for scoped addressing?

Since all addresses are validated before use, any failures that are the 
result of mixing addresses with different scopes should be non-fatal.

   How does your mechanism interact with multicast?

Unknown.

   How does your solution interact with link-local addressing
   How does your solution interact with Son-Of-Sitelocal (whatever that
   will be)?

Mixing of address scopes isn't likely to lead to useful results. Apart 
from that: no problem.

2.4.11 Are there any layer 2 implications to your proposal?

No.

   How will your solution handle referrals, such as those within FTP?

No change. Referrals are likely to fail after a failover. A separate 
solution for smarter referrals is desirable.

   Are you introducing a namespace that might involve mnemonics?

No.

3. Security Considerations

   How secure should a multi6 solution be?  This is a reasonable
   question for each solution to answer.  The author opines that the
   worst case should be no worse than what we have today.  However, any
   additional risks should be clearly stated by the authors.
   Considerable time should be spent on threat analysis.  Please see [4]
   for more details.

While redirection to an attacker's address is a new attack vector, I 
don't believe this is a big deal: with unmodified IPv4 or IPv6 over an 
insecure link, an attacker can observe and disrupt traffic today as 
well.

Iljitsch