[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: PI/metro/geo [Re: The state of IPv6 multihoming development]
Tony,
| You get away without uniqueness today by bounding the scope of
| uniqueness with a locator. If you explicitly remove that bounding
| function by insisting that the locator is separable and mutable, you
| make the problem of attributing security attributes to an identifier
| more complex.
Today's DOS attacks kinda imply that we don't trust the identifier or
locator.
| > And forged
| > identifiers are trivial today.
|
| By closely associating the identifier with the locator, forgery that
| actually results in a usable connection is traceable and
| compartmentalized with natural trust boundaries.
Yeah, but a connection is only ONE means of exchanging data. Do you trust
the single UDP DNS query?
| > In a new system there could
| > be (at least) a
| > mechanism
| > for providing optional authentication of the identifier.
|
| If the border router is going to use that identifier to look up the
| current locator, the authentication component would be a requirement
| prior to any modification of the locator table. This would also be a
| requirement before updating any DNS entries. (I bring up
| that last point
| because last week I was talking to Vixie about DNS trust
| boundaries and
| one approach would be to allow record updates when the
| record matched
| the source address of a node that had successfully
| completed the 3-way
| TCP handshake.)
I would happily agree that anything that is going to update the locator
entries in DNS needs to be secured. I would expect that this would
be part of normal manual DNS updates for multihomed sites and some
secure protocol would be involved for mobile hosts. This seems very
much analogous to what we have in v4 today. Is there some issue with
this approach?
Tony