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

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


El 07/03/2006, a las 21:07, Erik Nordmark escribió:


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. 



i am not sure about that...
i mean i don't think that locators learned through the DNS should be included in Ls(peer) for a shim context. The security of the binding between the ULID and the locator set is quite different in the case where it is secured with HBA/CGA and when it is learned through the DNS
So imho the information learned from the DNS is just hints about likely locators available for a ULID 

So, afaiu, it should work as follows:

a)- The case of deferred setup:
- Host A (with a single IP, IPA) looks up in the DNS for host B. It obtains IPB1, IPB2, and IPB3. (Suppose that at this point in time there is no shim6 context for none of possible ULID pairs) - Host A selects one of them and attempts to establish a communication. If it fails, it will try with another ULID/locator pair, until it succeeds. When it succeeds, it initiates the communication. - At some in point in time one of the parties decides to establish a shim context for the ulid pair being used, let's say IPA and IPB2. The locator set of host B has no relation at all with the information in the DNS, since it is obtained through the shim protocol. Suppose that the locator set for host B is IPB2, IPB3 and IPB4
- suppose that some time later, another application in host A tries to establish a communication with www.foo.com and the DNS returns IPB2, IPB5 and IPB6. - Now, if the application in host A selects IPB2 as the ULID for this communication, then the existing shim context will be used and the locators that were returned by the DNS and were not in Ls(peer) for the existent context will be not included as locators - If another address, IPB5 or IPB6 are used, then there is no shim context and it is like the previous case. 

b) the case of non-reachable ids

In this case the shim context is established up-front
- An application in Host A wants to initiate a communication with www.foo.com 
- Host A obtains form the DNS ULIDB1, LocB2 and LocB3
- the resolver returns ULIDB1 to the app and passes the information about ULIDB1 and LocB1 and LocB2 to the shim (how this is done in not in the current spec, but anyway) 
- then the app initiates a communication with ULIDB1
- when the shim receives an initiation of communication with ULIDB1, it will send the I1 packet using an alternative locator, LocB1. But this locator should only be considered as tentative, not as belonging to Ls(peer) (yet) - after the R1, and I2 exchange, when the R2 packet, it will contain the real Ls(peer) verified with HBA/CGA. If LocB1 and/or LocB2 are not in there, then they should not be included in Ls(peer) imho
- Suppose now that another application in host A wants to initiate a communication with www.boo.com. and that the results form the DNS are ULIDB1, LocB3 and that LocB3 is not included in Ls(peer) of the existent context for IPA1 and ULIDB1 - In this case, the resolved will pass ULIDB1 to the app and ULIDB1 and LocB3 to the shim, but the shim in this case already has a context for ULIDB1 and IPA1 - The app will initiate a communication with ULIDB1 and when it passes the packet to the shim, the shim will use the existent context imho, and use the existent Ls(peer) even if it does not contain the locators returned by the DNS. IMHO this is ok, becuase the information secured through CGA/HBA should be preferred over the one retrieved through the DNS - The strange case would be what if all the locators in Ls(peer) are unreachable right now, would it make sense to try with the new ones obtained from the DNS? imho it may be good to try, but just as a hint and not sending data packets until HBA/CGA and return reachability verifications are performed for this address
Do you think this would address the case you mention next or i am missing the case you were considering?
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.




(i am dropping the NAT topic for now... ok?)

regards, marcelo