Re: [Fwd: I-D ACTION:draft-nordmark-shim6-esd-00.txt]

[marcelo bagnulo braun <[e-mail]>]

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: [e-mail]
> Reply-To: [e-mail]
> To: [e-mail]
>
> 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
> [e-mail] 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:
> 	[e-mail].
> 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: <[e-mail]>
>
>
> _______________________________________________
> I-D-Announce mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/i-d-announce
>