-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 02/26/2013 09:50 AM, Marc Petit-Huguenin wrote: > I did not release a new version of this draft because as I was working on > improving it I discovered some issues and I was not able to decide on the > right solution. So I will present this in Orlando if I get presentation > time, but I would like to start the discussion now. > > The problem with Anycast is that there is no guarantee on the long term > that the same physical endpoint will be reached when using such address. > This is not a problem for short-term association, and even TCP is known to > work fine in this case. But in some cases (RELOAD section 3.2.1 second > bullet) a client can establish a long-term association with a bootstrap > server, and this association may fail. So the solution used in > -one-to-many-00 is to first send a STUN binding to the Anycast address > which will be answered with a 300 redirect that contains a Unicast address > that can be used for long term association. This also works fine with > multicast and broadcast. No problem so far. > > The problem is that it is relatively easy to redirect the client to the > wrong IP address, which is why this kind of mechanism requires some form > of authentication, so the client knows that the answer is from the real > server. Note that the client will anyway quickly discover that the IP > address does not use a correct certificate, so perhaps this attack is > harmless. > > One solution is to use the long-term authentication mechanism of STUN, > using the same username and password that was used to acquire the RELOAD > certificate. The client checks the MESSAGE-INTEGRITY in the response to > verify that the server really knows the password. I do not really like > this solution, because it requires to distribute and synchronize the > usernames/passwords on a lot of different servers. > > Another solution may be to use the fact that the bootstrap servers are > contacted after a certificate is retrieved from the enrollment server > (although an implementation may want to query the real address in parallel) > to establish a DTLS connection with the Anycast address, using this newly > acquired certificate, and then send the STUN Binding over it. That's my > preferred solution, but that looks a little bit complex for that purpose > (although it does not add more code to an implementation, as DTLS is > required for RELOAD anyway).
Reading the notes I took when trying to implement this, there is another issue which is that DTLS was never defined as transport for STUN (or TURN). So that would require an additional draft. - -- Marc Petit-Huguenin Email: [email protected] Blog: http://blog.marc.petit-huguenin.org Profile: http://www.linkedin.com/in/petithug -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJRM7tOAAoJECnERZXWan7ENs8P+wdo8mIB+0HXQDVI7KNKa2d4 iGxgNyrIbR53+gQum7n00LHjl0xP0hKuSa/INbCcWP7JY7EH1O5Z4VI4Bej4QRHA SlRc6MOrlB2c6Zjk/z/IxVeYQjXVhyKAejhRdlO9HzyKkF5BNnJHm6InQV/40J5s jGM7WiSXo0NzF2qXcVAcRf03UNPw5rGJtUQHSfY9u5ufjM89gi/a7/tuyoCgQMne zmQh0MUDF2hETth0XVXuM1W2mTeRsRN/DwLSrlvnF4jWDihDvrh6czvXWzvue1tf fzBiCeaj/j/eKiixODeSwSnlLqbuEodRVT0jPvqErAgzCLuoc6Ys8HboEQuQf/k9 h19uPeY9h4n/nTr8otZCt5jJUZbT6QPNyV8GNbT5yoaVXqrjEFzuyr9u567UcphJ 6vd+NOIzwT8y9PIrRdqC8bVGa1FhiYc3EVrdoex/M2Q26Vhxd9hHEG9W/tuuc6ot PhLEOjzK5ZBmhzaVSXK7r64AfLI/10nSMc/RUw96u5WoOKxyZpRVVki0y2EBQ14p UNIdvhw/fnRXEkIPCV85oYEeKXCXecZoSg4DhYfmesHJhWJ5CWf1CWcUrR1AF/Zv 0aPHCtF083yAoGIJeis/oxdkYqrkp3rXXOu0DwX0pxTIuM4iaq1Nj+DB+l3KR6rh w1hpklilL/clrGf0463g =dEOO -----END PGP SIGNATURE----- _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
