-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 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). Another issue: I was surprised to discover that it is forbidden by RFC 2373 to use an anycast address as source address of an IPv6 packet. I am not sure to understand all this, but it seems that the response in this case would be filtered by some NATs, which is the problem that we wanted to fix in the first place. OTOH, users of IPv6 NATs will get exactly what they deserve. Comments? On 01/14/2013 03:40 PM, Marc Petit-Huguenin wrote: > As agreed in Vancouver[1, this is a new draft that take all the > multicast/anycast and broadcast stuff that is removed in -base-24 and try > to make it working with anycast. Note that the solution proposed does not > require naked Ping, and that make bootstrap nodes easier to implement. > > Comments, suggestions and questions as always are welcome. > > > [1] https://www.ietf.org/proceedings/84/minutes/minutes-84-p2psip > > -------- Original Message -------- Subject: I-D Action: > draft-petithuguenin-p2psip-reload-one-to-many-00.txt Date: Mon, 14 Jan 2013 > 15:23:02 -0800 From: [email protected] Reply-To: > [email protected] To: [email protected] > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Anycast, Multicast or Broadcast Bootstrap Nodes for > REsource LOcation And Discovery (RELOAD) Author(s) : Marc > Petit-Huguenin Filename : > draft-petithuguenin-p2psip-reload-one-to-many-00.txt Pages : 6 > Date : 2013-01-14 > > Abstract: This document describes an extension to REsource LOcation And > Discovery (RELOAD) that permits to contact a bootstrap node using an > Anycast, Multicast or Broadcast IP address. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-petithuguenin-p2psip-reload-one-to-many > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-petithuguenin-p2psip-reload-one-to-many-00 > > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > - -- 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) iQIcBAEBCAAGBQJRLPXmAAoJECnERZXWan7EKFQQAKgahaJFIiHfF++LFFKpT6o+ awtKMCQzTOneZB4B9mZ6lghysUMe8ASu+aC/K7OKDyOHeIZIKKsizl0reQqKjQk7 lnuAtQJ/0H5fK0DMGdOeV20gJd9H7sKo/TJ/ZTx0OX32NwKGPfkkWn0mScaTGFMp ZAIhW2YzN+lu/3MZoBN9akeP8tkaNGXuK5Dz6Yi5JJy9l3aDE9MVCP2084NAxjrJ EpTPARyywTB/fhAUyRh2MQtuJkA3zu+PrRPIaStgVs8jpPyuHb1YTPjtQ0KeOR4y wS6bWQao1VNRaEDoIzhykw5mn7VR0Hw/aF8SBMdfnAuGo1gdukG6gMYeHQfikd3m Ore/qZvAlynExxGZygcCw4I0BS7TefTW/lAx3vEbrwtDt42+LW90cNLJJ6mvr/5f L3tD4wopnJos7Qwr6qB3PIkmg9ClkwOtAbksAVsrB3w9XG6ZU72fhmjRG4FPM3K0 49Kvf1wA9mo2lgf+SGoMEZP4EeYa/5gSEmV3aag6rFV1FvLb4aSfzZPUnafUi6cd MGENHidK3dEmRmHRlGGaNxW8vMRDRvT44XtWyeIp8LEzi2k/Lwu08EpVeD3NNoSM +3RxUXzvYEPgiQbb34XoLtuLDTVDVa1SEn4XTiX5EAdFyNs8JtPavyUdess/GKAt 4V48koqGrY0j4kCTkgLk =Oazn -----END PGP SIGNATURE----- _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
