[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:
Perhaps an option could be to get the identifiers and the locator from the direct DNS when the fqdn is resolved AND also perform the reverse mapping from the ID to the locator set, to verify that the information is there. So, when the fqdn is resolved, the host has all the information and can proceed with the communication establishment. But also, if after performing the reverse lookup it discovers that it is not properly populated, some kind of error message can be returned, so that the admin of the zone is informed. In this way, you can periodically verify the reverse zone, but reduce the cost involved in the verification operation. I mean there are two costs involved in the verification: the packet overhead due to the query and the added latency of waiting to obtain the locator information. IMHO the second one is the most problematic. With this option we would be eliminating the second one and just keeping the first one.
The above might work, but not clear what happens when there are slight differences in the two sets.
But when I thought about this a while back, I also ended up with some concerns about authority and security to speak for the ID->locator mapping.
For instance, if one application looks up www.foo.example and finds that the ID is X and the locators are L1, L2, L3. TCP gets X as the ULID, and the X->{L1, L2, L3} is installed in the shim layer.
A bit later some other application on the host looks up www.bar.example and finds that the ID is also X, but that the locator set is different. This could be a case of both domains being hosted on the same server, or it could be a security attack.
Thus at a minimum, when there is a a conflict like this, one could have to check the reverse map. But what happens should the reverse lookup fail (NXDOMAIN) or time out when we do the deferred lookup? Should we fail the original communication (to www.foo.example)? Fail both the original and the new attempt (to www.bar.example). 

Having it fail immediately might be more predictable.
So there are some difficult tradeoffs.
agree but i guess that it is easy to determine that in the NAT case (in the general case). I mean, if the other end sees a public address and we are using a private address, then the private address is unreachable from the peer and must be substituted with the public one received in the option. 

If not sure it is easy.
Take a multihomed host with two NICs and 2 prefixes on each.
The host has 4 locators; L1 and L2 on NICa and L3, L4 on NICb.
It finds out that when it is sending using L1 as the source, the receiver sees the packets coming from L1'. Thus this mean that L1' is a replacement for L1? Probably (at least when talking to that destination). But does it also replace L2? I have no idea. 
Should it have any impact on the locators on the second NIC.



If both v4 addresses received are public, then this is TE and both are ok.
How can you tell if an IP address is public or not? While checking for the 3 RFC 1918 ranges might capture 90%, I think there is NATting going on even when the address space behind the NAT is global IPv4 address space.
(The problem is that now some very big sites are starting to use public addresses when they run out of private addresses (http://www.arin.net/policy/proposals/2004_3.html) which would break the simplicity of the approach. But even in this case, the local host should be able to know which are the addresses reserved for private use and apply the same heuristic mentioned above
Another reason why you can't *syntactically* check whether an IPv4 address is NATted or not. 

Doesn't the remote host need to know as well?
yes, but shim is supposed to be able to deal with failures and the NAT loosing its state can be seen as a failure. So, the shim will be able to recover from this and even recreate the NAT state. Probably we need some additional logic to be smart enough to identify that what is going on is that the nat is loosing state and increase the keepalive frequency. I mean, in the case of the shim, the communication can be recovered from a nat loosing state and the state in the nat can be easily recovered.
Yes, there is definitely a lot of extra work needed to make this a full fledged NAT traversal mechanism. Which is why I don't want to spend time on it.
So what we need is a locator selection algorithm that is likely to take into account the same issues that RFC3484 does, but with different trade-offs being made, right? 

Right.

  Erik