-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 02/26/2013 11:22 AM, Thomas C. Schmidt wrote: > 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 ;)
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 > 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/ >>>> > >> _______________________________________________ P2PSIP mailing list >> [email protected] https://www.ietf.org/mailman/listinfo/p2psip >> > - -- 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) iQIcBAEBCAAGBQJRLQ02AAoJECnERZXWan7E/F0QAJ2qysycQK5q+OFMPE90TrPH L1Q+y4nJtBQ2HOog4wAqW1ZyK9edwXtkDDFycqF0zBiGKa5Tvq/g+CLgEyew4Kip AiXhKjroqHFlhsVyf0qq+xFmRfBpNqPEbId44AzIK0INsAgSgcCQWQ2Ufn5kyrLd 4F4of5flFLfekSOBZkA08PdDwsr5jhcGS/ccadiCecXnWHxdgfbDRjNTHSdoaqCM W2JzM9soaJEbyOy7uj09lihfnwb+/rsANNTINmUbqOYMfubXp+6dY6D+7w3+rhTe tyNDJxMwvTeNUaMqnkulB84oM9FtEgkrtITnFnzvCF0k6x0ZrLbH0un7AVex8FyW HmQyAl7s8Mqlb8xwL3vOEQqSa4euCGW9vSHqF9zu6omvoBRP6u8finKBMclygFij VNByf3kBk9zAvhLG/1BE0TdbR5UCtsq6Fv0YmJEXFaHMVggTqMM7SW1q1RFuRKiD rD0O6cKmlRus77wz4RhOK1lFlgLej+1tcFQSdKTzY1j12MeNpZhD3t60yI5c4cC1 Bpq+Bgz7lJ++3AISAQQQhqDghtvaWo+GaPrXtWgHYnYgu2/3PzigdE7IzmE00kYr kccKk/OgjwfvUhfTqqLLgIuHVR4VW7Jo8Nj+Sl5xOcU7n4p9Nt6X4m7XG74EV4QG xy87M7jwHY1M2MiU1/9F =0mBG -----END PGP SIGNATURE----- _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
