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

[Erik Nordmark <[e-mail]>]

marcelo bagnulo braun wrote:
> Hi Erik,
> 
> I think the draft is very useful and provides very good insight of these 
> interesting issues.
> Allow me to do some comments.

Thanks for your comments.

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

Centrally allocated ULAs would be AFAIK.
But I though (and could be wrong) that only the random ULAs were moved 
forward.

> 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

Good point.

> 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

Yes, apart from the point below ;-)

Putting the ids in AAAA records, assuming it can be made to work, have a 
performance benefit. Without it, the host has to
  - look for an ID RRset
  - if none found look for AAAA RRset
  - if none found, look for A RRset

This is extra overhead when the target host doesn't have any ID RRs.

If we could put the identifiers in the AAAA RRset in such a way that 
legacy IPv6 hosts wouldn't try to communicate with them (due to the RFC 
3484 ordering putting them last in the list), then even for target hosts 
that don't have IDs there is no extra DNS lookup.

>   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

FWIW it isn't only referrals and the like that would be a problem when 
the ID->locator lookup isn't populated; also the case when the shim 
discards the context state would not work since there wouldn't be a way 
to rediscover some locators once the context state is gone.

My take is that we are doing shim6 and its extensions to gain better 
robustness of the network as seen from the communicating applications. 
Thus saying that we don't care about robustness by not ensuring that the 
id->locators lookup mechanism is populated doesn't make much sense to me.

There isn't a free lunch here - introducing a separate  128-bit 
identifier space provides significant benefits, but also comes with some 
cost. But this cost of doing the id->locator lookup only occurs when 
creating the shim6 context, thus it is NOT for every connection.

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

OK. Without any NAT support?

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

We can encode the address type in different ways. One way would be to 
use a flag field in the verification method. Another would be to use the 
IPv4-mapped address format (::ffff:1.2.3.4). Both would work AFAIK.

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

This is non-trivial. It also would need to know which peers are on the 
near and far side of the NAT, since it needs to use different locators 
in the two cases.

> 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

I'm concerned about the slippery slope.

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

If the peer has only one ID and this host has only one ID, then the 
selection is trivial.
I don't know of a use case where each host would have multiple IDs.
(We do need to make sure that the source ULID is a non-routable address 
if and only if the destination ULID is a non-routable address.)

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

I guess there are two aspects of locator selection and the draft focuses 
on the TE aspects (selecting between different global locators with 
different prefixes based on the TE wishes of the destination); selecting 
  locators with different scope, home vs. CoA, private vs. public is the 
other part.

I suspect that one would want some coupling between the ULID selection 
and the locator selection. For instance, a host that wishes the privacy 
benefits of temporary locators presumably also would use a temporary ULID.

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

What part of RFC 3484 do you see as useful for this?
As an example, one way to explore other locators after a failure is to 
try one that is maximally different from the failed locator (i.e. 
differs in the leftmost bit) since such a locator might be a more 
independent path.  The point with this example is that RFC 3484 takes no 
such consideration into account.

> 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 was actually envisioning that the source locator selection would be 
driven by the same type of information (priority and weight) as the 
remote end sends us (in the Locator Preference option) for the 
destination locators.

Thus one way to do this is independent selection of source locator 
(based on the locally configured priority and weights) and destination 
locator (based on the Locator Preference option).

I don't see what the RFC 3484 table would add; we do need to consider 
address scope etc which is something to carry forward from RFC 3484.


> 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

The AAAA records for a resource record *set*, hence there is no order 
defined. People might wish that the DNS provided a *list* instead of a 
*set*, and in some cases one can pretend it is a list and get some 
benefits, but it is still defined to be an (unordered) set.

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

That bullet just says to inform the peer that its locators were 
rewritten in a new way.

But the draft mentions somewhere that the host can "adopt" a locator 
that the routers using, and if it does this, it would presumably send an 
Update Message to the peer saying that it is ok to send to this new 
locator (and provide the CGA signature to prove it).

> 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

One of the interesting things is the combination of the unroutable ULID 
and getting router feedback during the context establishment exchange 
(which will be done before any ULP packets are exchanged in that case).
If we only allow rewriting on packets with the payload extension header 
we wouldn't have that capability of early locator selection according to 
the policy implicit in the router's rewriting.

    Erik