[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: transparent addrsel policy adjustment for outbound TE
El 05/04/2006, a las 14:54, Pekka Savola escribió:
On Wed, 5 Apr 2006, marcelo bagnulo braun wrote:
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
Could be though, it could probably be trivial to define a something
special like _shim6._ip.FQDN
makes sense
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.
Simple routing changes don't help if ingress filtering is in place,
because the sources select the addresses and have to be routed in a
very restricted manner.
right, i was thinking in two scenarios:
- in one case, we have routing system based policy, in which case we
need router rewriting
- in the other case, we have policy distributed to the hosts, and it
influences source address selection
A part of this is an alternative means for "policy distribution" for
hosts, I guess.
ok, i see, you are considering this as somehow centralized policy
server where the local hosts can get policy information from. Something
like NAROS, but using the DNS instead of a new protocol.
Yes this could be an option, but defining a dhcp opcion for
distributing rfc3484 policy table could be also. I guess this depends
on how much information the policy implies. I mean, in one approach,
the host stores all the policy information in the rfc3484 policy table
(which may work if this is not much information and it has a good
performance because it does not require a query for each new
destiantion). the other approach, the host only stores the information
about the destiantions that it is communicating with, which requires
less storage capability but imposes a query each time a new destiantion
is contacted.
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...
The problem is that DNS caches in the middle will cache both IP_1 and
IP_2, but lose the "preference" which is conveyed by the weighted
address ordering, because from the DNS cache perspective IP_1 and IP_2
are equivalent.
but my assumption is that the remote resolver will also query for the
SRV record as local hosts do, so the SRV information will be retrieved
also (perhaps from the caches, but this is no problem if it is not very
dynamic)
wouldn't this work?
regards, marcelo
So this only works if there are no DNS caches in the middle, AFAICS.
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings