Re: I-D ACTION:draft-nordmark-multi6-sim-01.txt (Fwd)

[Erik Nordmark <Erik.Nordmark@sun.com>]

> ADOPTION
> 
> 1. Modification to both endpoints, using a shim layer directly above IP

Yes.

> 2. Addition of a DNS record type and expected modification of DNS servers, to
> do differential processing, based on presence or absence of records of that
> type, when a query for that record type is made

There is a new DNS rr type needed, but there is no differential processing
in the DNS servers. The hosts query for the new "ID" record and AAAA records.

> 3. Modification of intermediate routers, to do locator re-writing.

Not required from the outset, but for some failures having locator re-writing
simplifies and speeds up failure recovery.
Thus one could start deploying this type of approach without any upgraded
routers.

> DESIGN
> 
> As the spec notes, deferred validation of new locators adds complexity to the
> protocol.
> 
> My question is, therefore, why you chose deferred validation, versus
> automatic validation? In general, it would be helpful to understand the
> reasons for the various choices made in SIM.

The overhead of performing a public-key signed response to the challenge 
is the concern that made me explore the omitted validation (until there
is a peer locator change).
I don't claim to fully understand the tradeoffs here, but playing around
with when validation is performed, perhaps also combining it with different
strength validation, is something we should do to explore the design space.

> The use of context tags in every packet appears intended to provide a higher
> level of protection than exists in current IP.

Don't think so.
The context tag is needed to be able to identify the replacement needed
for the IP address fields before passing the packet to the ULP.
Since the locators in the packet are not used for this there has
to be some "key" in the packet to indicate the replacement needed.

There is also a security aspect of the tag having to do with packet injection.
See section  4.4.  "Accepting Packets from Unknown Locators"
in draft-nordmark-multi6-threats for the threat.

I can think of 2 ways to address that threat:
 - a packet with an unknown source locator is dropped (or queued by the
receiver)
   until the source locator has been verified.
 - a packet with an unknown source locator is accepted if it contains the 
   correct tag
SIM takes the second approach.
The first approach would be more secure than today's Internet with
some deployment of ingress filtering.

> 1) What is to prevent a wire-tapper from using the copying the tag?

Nothing - which is why it isn't any stronger that today's Internet - today
an on-path attacker can inject packets and even ingress filtering
can't prevent that.

> 2) If sites want this kind of per-packet extra protection, why not use IPSec
> or TLS?

It isn't extra if you consider that there is some deployment of ingress
filtering which prevents injecting packets with spoofed source addresses from
many, but far from all, attachments to the Internet.

  Erik