Hi Marc,
just a short remark on the use of IPv6 Anycast addresses:
RFC2373 is deprecated by RFC4291 and this newer document removes the
restrictions on using Anycast as a source address.
So this one issue should be gone ;)
Cheers
Thomas
On 26.02.2013 09:50, Marc Petit-Huguenin wrote:
-----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
--
Prof. Dr. Thomas C. Schmidt
° Hamburg University of Applied Sciences Berliner Tor 7 °
° Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany °
° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 °
° http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-8409 °
_______________________________________________
P2PSIP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/p2psip
