[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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