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

From: Dave Crocker <[email-masked]>
Date: Sun, 2 Nov 2003 09:31:30 -0800

Erik,

EN>         Title           : Strong Identity Multihoming using 128 bit Identifiers (SIM/CBID128)

It would be helpful for the different proposals and specifications to
discussion adoption, administration, use and performance issues, as well as
design rationale.

Your spec has the Protocol Walthrough, which gives detail about some of the
usage effort. Explicit discussion about the critical adoption requirements
would be particularly helpful.

I am probably not reading the specification correctly, but it appears that SIM
requires:

ADOPTION

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

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

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

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 use of context tags in every packet appears intended to provide a higher
level of protection than exists in current IP.

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

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

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

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 3 Nov 2003 14:16:31 +0100 (CET)

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

Yes.

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

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

> 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

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

---

From: "marcelo bagnulo" <[email-masked]>
Date: Mon, 3 Nov 2003 15:04:56 +0100

> 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?

I like defferred validation, becuase you don't incurr in aditional costs
until you really need to. I guess that most of the communication will only
use one locator during its lifetime, so it seems wasteful to verify multiple
locators in this case.

Regards, marcelo