Subject: [P2PSIP] Bootstrap redirection authentication [was Re: Fwd: I-D Action: draft-petithuguenin-p2psip-reload-one-to-many-00.txt]

From: Marc Petit-Huguenin <[email-masked]>
Date: Tue, 26 Feb 2013 09:50:32 -0800

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-masked] Reply-To:
> [email-masked] To: [email-masked]
> 
> 
> 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-masked]
Blog: http://blog.marc.petit-huguenin.org
Profile: http://www.linkedin.com/in/petithug

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Tue, 26 Feb 2013 11:22:31 -0800

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
>
> -----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-masked]
> 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 °

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Tue, 26 Feb 2013 11:29:59 -0800

> So this one issue should be gone ;)

Great, thanks.

> 
> Cheers
> 
> Thomas
> 
> On 26.02.2013 09:50, 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 
> verify that the server really knows the password.  I do not really like
> this solution, because it requires to distribute and synchronize the 
> (although an implementation may want to query the real address in parallel)
> to establish a DTLS connection with the Anycast address, using this newly 
> (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?
> 
>>>> 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.
>>>> 
>>>> draft-petithuguenin-p2psip-reload-one-to-many-00.txt Date: Mon, 14
>>>> Jan 2013 15:23:02 -0800 From: [email-masked] Reply-To: 
>>>> Title           : Anycast, Multicast or Broadcast Bootstrap Nodes
>>>> for REsource LOcation And Discovery (RELOAD) Author(s)       : Marc 
>>>> 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.
>>>> 
>>>> 
Internet-Drafts are also available by anonymous FTP at:
>> _______________________________________________ P2PSIP mailing list 
>> [email-masked] https://www.ietf.org/mailman/listinfo/p2psip
>> 
> 

- -- 
Marc Petit-Huguenin