On Mon, Apr 27, 2015 at 3:50 PM, Christian Huitema <huit...@huitema.net> wrote: >> Which is why I propose what is in effect a STLS (Staleless TLS) in >> which each UDP request packet (optionally) contains the full state >> required to decrypt it at the server. > > Without going in the details, there are two types of solution to the anycast > problem: either some form of pinning, so requests from a given context are > guaranteed to arrive at the server with that context; or, somehow ensuring > that the requests carry enough state that they can be understood by any > server in the pool. > > I understand how to do pinning: a first transaction to the anycast address > returns the unicast address of the relevant server. Not perfect, because it > adds a roundtrip during the initial setup, but easy to understand.
I am not too bothered about the initial setup. That is a one off thing that can happen as soon as the IP stack is initialized. Even doing it in application space there is usually a gap between someone starting a browser and clicking on a link. > I am not sure about the way to carry "enough state in each request." Kerberos tickets, or rather an opaque blob that the service can put whatever format ticket it likes. >Especially if we want to do PFS, which means negotiating different session >keys over time. I assume that the client could learn a "temporary key" that is >understood by all servers in the pool, and use that to encrypt the messages. >But then that requires a fair bit of coordination between the servers in the >anycast pool. How much PFS do you want? Easy enough to rotate a kerberized ticket on an hourly basis or so. > -- Christian Huitema > > > _______________________________________________ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
