[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Fwd: I-D ACTION:draft-nordmark-shim6-esd-00.txt]
Hi Erik,
I think the draft is very useful and provides very good insight of
these interesting issues.
Allow me to do some comments.
About full id/locator split in shim6
In section 2.1 it is stated that
Since we are likely to have applications communicate to both hosts
which have an IP identifier and those which only have the IP
locators, it is highly desirable to be able to have a syntactic means
to tell an IP identifier apart from an IP locator. A reasonable
approach is to allocate a small subset of the IPv6 address space [23]
to be non-routable IP identifiers, in a similar means to the KHI
approach [24].
The desired semantics of an IP identifier is to be a name that refers
to an instance of the IP protocol. Hence it should not be bound to a
particular network interface. Also, it is desirable for the
identifier to be long term stable, for instance ensuring that the
identifier survives renumbering.
As we will discuss below, for application referrals to work using
128-bit IP "addresses" as handles for another host, there has to be
an efficient and scalable way to look up an identifier and find the
locators. An obvious way to get scalability is to do hierarchical
allocation of the identifiers, since this allows for a scalable,
hierarchical organization of a lookup system and also ensures that
the identifiers are unique.
While it certainly isn't the only possibility, in order to work out a
complete picture, this document suggests such a hierarchical
allocation, in such a way that at least 64 bits of the identifier is
left to each site to allocate. (With 64 bits we can use CGA to
"prove" identifier ownership as a way to prevent redirection attacks
from off-path attackers.)
all the above conditions seem to be fulfilled by ULAs, but they are not
mentioned anywhere (only in the references)
did you have something different in mind or ULAs are a good candidate
for this?
In sections 2.4 and 2.5 the handling of referrals is presented.
I guess that an additional problem that shows up in the case that ids
are not valid locators is the support of legacy hosts.
I mean, since the ones that are passing ulid information are the
applications, it is possible that the ulid ends up in a legacy host
that does not implement the shim and that is not able to translate the
id into a locator, even if the directory service is available.
So, even with this approach, the referral case still presents some
issues imho
In section 2.6 Design Alternatives it is stated
If the identifiers are placed in the DNS using AAAA records, then the
lookup for the AAAA record set (to find the identifier) might also
return a list of locators.
another alternative that probably would result in similar behaviour
would be that the identifier is included in the identifier record, but
that the same query that returns the ID record also returns the locator
set associated to this identifier in the additional information field
Such information would be delivered by the resolver to the shim process
which would store it for when the packet addressed to the identifier
arrives
Such a list can potentially be useful to
avoid the ip6.arpa lookup to find the locators. But relying on this
means that the reverse lookup from the identifier will only be used
in uncommon cases such as:
o The shim6 context state having been garbage collected too early,
and the upper-layer protocol sends down a packet with a
destination ULID which is a non-routable identifier.
o Application callbacks, referrals, and long-lived application
handles [27] that are IP addresses.
For this reason it makes sense to be more consistent and always rely
on the reverse lookup when the context is established.
I fail to understand this point. I mean avoiding extra DNS lookups is
good, since it reduces latency and load to the servers. why do we want
to impose this? just to make sure that the reverse information is in
place i.e. that the reverse tree is properly populated? i think this is
an expensive price to pay for this and i would rather prefer that those
that have the reverse tree poorly populated simply have problems with
the referrals rather than imposing a penalty to all shim communications
About using v4 locators
I think that supporting v4 locators would be very valuable for the
protocol. I would suggest to move this to a separate document and adopt
it. (maybe it could be included in the base spec since it seems quite
trivial to do)
The option proposed for this in the draft is:
When CGA is used to prevent redirection attacks in shim6, there is no
constraint on the locators that are used apart from host B must know
its own locators so it can pass it them to host A. In particular, we
can use IPv4 addresses as locators; this doesn't require anything
more than defining how an IPv4 address is carried in the 128-bit
fields in the Locator List option.
I wonder if it wouldn't be better to change the verification method
field to a generic Flag field and use some bits there to specify the
address family, what do you think?
w.r.t. NAT i guess that an additional consideration is how does the
host detects its own addresses in order to include them in its own
locator set and communicate them to the peer. Of course, shim should be
able to detect private addresses and not include them in the Ls(local)
IMHO a reasonable trade-off would be now to specify how IPv4 addresses
could be used as locators when no nat is involved and leave the nat
support for further study
About TE and source address rewriting by exit routers
In section 1.2 it is stated that
o With ULIDs that are non-routable identifiers, there will most
likely be only one identifier for the destination as well as the
source. Thus the role of RFC 3484 is largely removed. But there
is an additional step of looking up the identifier to find the
locator, and at that point in time it makes sense to consider
traffic engineering for selecting the initial locator pair.
The point here, i guess is that RFC3484 is used today to select
addresses for initial contact. As those addresses are going to be used
both as ULIDs and locator, then RFC3484 is currently used to select
both.
In the case that we use a ULID that it is not a locator, then which
mechanism are we going to use to select each of them,
In the draft it is assumed that a single identifier will be available
for an endpoint. I don't see the need to have more than one, but i
guess it would make sense to consider the case, but we can probably
deffer this till later. However, it seems reasonable to have more than
one locator. The question would be at this point why not use RFC3484
(or RFC3484bis) to select among the multiple locator pair combinations?
In other words, i don't see that the role of RFC3484 removed, but
rather that RFC3484 is used to perform locator pair selection rather
than ULID pair selection... does this makes sense?
Moreover, i would wonder if it didn't make sense to use RFC3484 to
select locators after a failure i.e. to select the locators to explore
after a failure is detected using RFC3484 for that, or even if we have
multiple address pairs that are working as locators, to use RFC3484 to
select which one among them to use to rehome the communication.
It would also make sense imho to explore the relation between RFC3484
and the locator preference option. I mean, the preference option is
used by the local host to inform the peer about its preferences when
the peer selects the locator to use. RFC3484 is about which of the
local locators will the local host use for communication. Probably,
there these two are somehow related i.e. in many cases probably the
local host would want that these two criteria are similar i guess
Essentially, the question is whether RFC3484 is a good candidate for
locator selection and how this relates to the preference information
available in SHIM.
in section 3. Traffic Engineering Support
The traffic engineering pieces that might be desirable and that are
easy to implement in this model are outlined in this section. If the
ULID is a routable locator, then it makes sense to recommend that
applications use DNS SRV records for the initial (non-shimmed)
contact, and also provide at least a DHCPv6 option by which a site
administrator can control what each host in the site uses in the
shim6 Locator Preference option.
In the case when the ULID is a non-routable identifier, a different
set of mechanisms are desirable. Instead of using DNS SRV records
for the lookup of the domain name of the peer, we want similar
control when looking up an identifier to find the set of locators.
I guess that the information in SRV records is about the peer's
preferences about its own locators
The same thing w.r.t. the preference information received in the
preference option of the shim protocol
however, the local host may also have some policy w.r.t. which locator
prefer when there are multiple of them for a given destiantion.
I guess that the local preferences will be expressed in the RFC3484
table
I guess that an additional issue to consider would be the interaction
between remote policy information obtained through SRV/preference
option and the local policy information in rfc3484 policy table
later on in section 3.1 Recommending use of DNS SRV
In shim6 as specified, the host rely on existing DNS mechanisms, such
as AAAA records or any other mechanism, to find a list of locators to
try. When AAAA records are used, there is no mechanism for the
destination site to express any ranking for primary/fallback, or any
mechanism to spread load across the paths that are represented by the
locators, since the AAAA resource record set is treated as a set with
no implied order.
This is not strictly true, i believe
I mean, rfc3484 preserves the order of the received locator list if no
rules apply
So, if for the local host all the addresses are equal, then the order
in which the locators are returned by the DNS is preserved, and the app
is likely to pick the first one
So, changing the order in which DNS returns the locator list would
likely result in some form of load sharing AFAIK
Perhaps if the order is always the same, a behaviour similar to primary
backup could be achieved.
I agree though that using SRV records would result in a more fine
grained well documented behaviour
In sections 3.4 and section 3.5 a mechanisms for supporting source
address rewriting by hosts is presented.
I have two comments w.r.t. to the mechanisms presented:
First, i think that the idea to carry the Sent Locator Pair and
Received Locator pair options to discover and allow coordination
between routers and hosts is very clever. As i understand it the main
focus is putted in the case where host A learns through this option new
locators of its own.
However, it may be case that a host receives a payload packet with a
new locator from its peer i.e. the source locator is not included in
Ls(peer). In this case, it will accept the packet since the CT match,
but it cannot use it to send packets until a CGA/HBA verification of
this locator is presented by the peer. However, when it sends the new
locator in the received locator option, the peer should sent an Update
request the includes the new locator signed with CGA. I am not sure if
this is what is expressed in the last bullet of section 3.4...
Second, i think that the presented mechanisms are potentially very
useful for rewriting payload packets, but i really don't think it worth
the effort to rewrite the source address of the shim control message. I
mean, they are a fairly reduced amount of packets, so i guess that they
don't really affect TE considerations. Supporting this adds additional
complexity to a protocol which is already fairly complex imho. I mean,
i guess it can be done as you present in the draft, but i don't think
we win much with allowing rewriting of these few packet and we would be
adding much complexity. I would keep it just for data packets and not
for signalling packets
regards, marcelo
El 01/03/2006, a las 21:45, Erik Nordmark escribió:
-------- Original Message --------
Subject: I-D ACTION:draft-nordmark-shim6-esd-00.txt
Date: Tue, 28 Feb 2006 15:50:02 -0500
From: Internet-Drafts@ietf.org
Reply-To: internet-drafts@ietf.org
To: i-d-announce@ietf.org
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Extended Shim6 Design for ID/loc split and
Traffic Engineering
Author(s) : E. Nordmark
Filename : draft-nordmark-shim6-esd-00.txt
Pages : 25
Date : 2006-2-28
The Shim6 protocol provides for locator agility while satisfying the
'first, do no harm' security requirements. This document outlines
some extensions to Shim6 that in addition provides complete
separation between identifiers and locators, and allows routers to
rewrite the locators in the shim6 packets as a way to provide
traffic
engineering information to the hosts.
The document also outlines a simple extension to allow shim6, with a
CGA upper-layer ID, to operate using IPv4 addresses as locators.
The purpose of this outline is to stimulate discussions.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-nordmark-shim6-esd-00.txt
To remove yourself from the I-D Announcement list, send a message to
i-d-announce-request@ietf.org with the word unsubscribe in the body of
the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.
Internet-Drafts are also available by anonymous FTP. Login with the
username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-nordmark-shim6-esd-00.txt".
A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
Internet-Drafts can also be obtained by e-mail.
Send a message to:
mailserv@ietf.org.
In the body type:
"FILE /internet-drafts/draft-nordmark-shim6-esd-00.txt".
NOTE: The mail server at ietf.org can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e. documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
Content-Type: text/plain
Content-ID: <2006-2-28145153.I-D@ietf.org>
_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www1.ietf.org/mailman/listinfo/i-d-announce