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

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


El 02/03/2006, a las 22:42, Erik Nordmark escribió:



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. 



Yes this makes sense to me



  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. 



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



I agree that we should care about robustness
But my point is that if someone is doing shim and it is using non routable ids, then he probably cares about robustness and so he should know that he must properly populate the reverse DNS. I mean i consider that the penalty of artificially imposing a reverse lookup when establishing every shim context in order to make sure that the reverse entry exists, seems an overkill to me (especially because we will be always paying the cost even once the reverse dns is properly populated for these id)
There isn't a free lunch here - introducing a separate 128-bit identifier space provides significant benefits, but also comes with some cost. 

Yes, but imho we should try to minimize that cost.
Having to do the ID->loc lookup when a referral, call back, lost context event occurs, is the cost that we really need to pay Having to do it for every shim context establishment is not strictly necesary, and imho we should avoid that 





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?



Yes, without NAT support for the base spec or initial v4 support.
Then we should move on and figure out how existent NAT traversal techniques are suitable for SHIM6 and see if additional stuff is needed 


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. 



sure
but i guess that my point is that if already identify that we may need additional flags about the address information, it would be a good option to redefine the verification method to a generic flag octet, in order to support future flexibility (this is somehow independent of the option selected for the v4 address, is more a general observation)
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. 



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



Ok, let's explore this a bit more...
wouldn't the Sent locator option and the received locator option be useful for dealing with NATs? I mean using these, a host can find out if the addresses were rewritten (whether by a router or a nat doesn't matter i guess), and discover its own addresses and eventually add them to the Ls In addition, as you mention in the draft the failure detection mechanism could be used to preserve the NAT state if detected Probably the piece that is missing is somehow of rendez vous server for initial contact for hosts behind nat 



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



right
I guess that locator selection incorporates several elements:
- Rechability
- Preferences with respect the different types of locators (CoA vs. HoA, scope, private etc) - TE/policing issues (including local preferences and remote preferences (the preferences of the peer))
RFC3484 can be used to express the tree items somehow (with its limitations) (note that it does not help to determine if an address is reachable or not, but it does take this information into account when performing dest address selection) 

In addition, the locator selection is performed:
- when the communication is initiated (whether when a routable id is selected (just RFC3484) or when a non routable id is used and the shim selects a correspondent locator) 
- when a failure occurs,
- because of TE considerations, a host may choose to change the locator
I would say that in any of those cases, it is importnat to take into account all the aforementioned 3 items, so i guess that RFC3484 may be a good candidate for locator selection
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.
But not only availability must be taken into account for exploring and rehoming i guess. First of all, you probably want to take into account considerations like scope, HoA vs. CoA, private vs. public addresses when selecting which address to explore Second, you also may want to take some policy/TE considerations into account (e.g. suppose you have a site with 3 links, 2 of them with a flat rate and the third one with per traffic rate. Probably you will want to use always that flat rate first and only fall back to the per traffic rate if those two ae down, independently of the number of bits that the source address has in common)
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. 



Not sure i understand the last sentence.
but i guess we need to consider scope/HoA/private etc when selecting destiantion addresses
And i guess that a multihomed host may also have preferences about which destiantion address to use for reaching a destiantion and may want to override the preferences of the peer, especially when he is sending traffic. I mean, each end has the possibility of selecting the locator pair that it want to use for sending. It may take into account the peer's preferences, but it will have the final choice in any case. does this makes sense? 

So for both of these issues, RFC3484 could be useful
In any case, i guess your model is much direct and maybe we could adopt it and not precluding more complex setups in the future 



....




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.
but how early is this compared to the case where no rewriting is supported for control packets? I mean, in the case of no rewriting for control packets, the first payload packet would get rewritten and the capability would only get delayed for 2 packets i.e. the shim context establishment packets, which i don't think is an issue... 
but probably i am missing the point you are making...

Regards, marcelo



   Erik