Re: transparent addrsel policy adjustment for outbound TE

[marcelo bagnulo braun <marcelo@it.uc3m.es>]

Hi Pekka,

El 31/03/2006, a las 12:28, Pekka Savola escribió:

> Hi,
>
> Reading the extended shim design draft, in particular the discussion 
> on app modifications to do SRV lookup triggered the following thought.
>
> I'm pretty sure someone must have run this thought experiment before, 
> so pointers would be useful if so.

well, i don' recall hearing this before, not in the multi6/shim6 forums

> When applications perform DNS lookups and get multiple responses, the 
> _resolver libraries_ could, based on transparent (to the app) SRV 
> lookups or policy database, "weigh" the getaddrinfo responses given to 
> the applications.  That is, because the apps by default try the 
> addresses in the order they get them from getaddrinfo, instead of 
> returning the records in round-robin fashion, the resolver could very 
> well return certain addresses first (e.g.,) 90% of the time, some 
> others 10%.  (The obvious other address destination selection criteria 
> should be applied first.)

This seems like a good idea to me indeed. This would require only 
updating the resolver and relying on the apps querying for SRV records
However, SRV records have this Service.Proto.Name format that may not 
be the most appropriate for the shim6 needs, so perhaps it would make 
sense to define a new record type that has similar weight priority 
information, but that it has a node scope, i.e. does not depends of a 
service in particular.

I mean, since the SRV record has this special name associated, it may 
not trivial for the resolver to figure out which SRV record to query if 
the application wants to initiate a communication with machine1.foo.com

so perhaps it makes sense to go all the way and use new RR

> This would not have any negative impact on the application as all the 
> addresses would still be there but the ordering would just be modified 
> based on preferences, though running transparent SRV lookups could 
> incur delays etc. if it's not done in parallel.

> This could be very effective means for outbound TE decisions without a 
> need to touch applications at all.

well, actually i see it exactly the opposite :-)
this is really useful for inbound TE

I mean, outbound TE is the easy part, since the multihomed site is in 
control of the packets and it can route them however it wants to. So, 
outbound TE can be done by affecting routing or by configuring the 
source address selection policy table and so on.

The difficult part is how to influence incoming packets, that are not 
in our scope. This is where the SRV records and all this stuff becomes 
useful

> This doesn't really help with inbound TE though.  (One could add 
> similar function the site's authoritative DNS server, and unmodified 
> resolvers might comply with that policy, but caching DNS servers would 
> mess this up.)

why?
i agree that the expressed policy has to be quite stable, i mean, the 
cache will introduce certain inertia, and changing the preferences may 
take some time, but at least you can express some preferences about 
which addresses the site preffers for incoming communications...

> One could imagine that a part of inbound TE (for sessions which 
> originate at the site) could be handled with slightly similar source 
> address selection policies, but this doesn't help with inbound TE for 
> traffic originated from the Internet (but you could add the SRV 
> records or whatever if you care about this).

well, the idea is that resolvers do care about this and they will do 
this processing.
What is needed next is to see how to combine this with the local 
preferences...

Regards, marcelo


> --
> Pekka Savola                 "You each name yourselves king, yet the
> Netcore Oy                    kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings