Subject: Re: [P2PSIP] Anycast support in RELOAD, again

From: Cullen Jennings <[email-masked]>
Date: Sun, 4 Nov 2012 09:23:15 -0700

I like your solution but given that base is deployable without this, I wonder if you could just write this up in a separate draft that was an extension to base?

On Sep 20, 2012, at 10:29 , Marc Petit-Huguenin <[email-masked]> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> In Vancouver we decided[1] to remove the support for
> multicast/anycast/broadcast in the RELOAD spec, following a discussion back in
> Taipei about problems for supporting anycast.
> 
> I thought a bit more about the anycast problem, and I found a solution to this
> problem that is simple and so that would permit to keep the text in -base.
> 
> To summarize the problem, a bootstrap node cannot be directly running on an
> anycast address because the real destination can change at any time, and that
> would break DTLS.  That can be solved by adding the IP address of a bootstrap
> node not running on the anycast address in the PingResponse, but unfortunately
> this is not a compatible change.  There is other problems with this approach,
> related to the fact that the Ping must be sent without DTLS (naked Ping).
> 
> But, as per -base section 6.5.1.4, all RELOAD nodes are also STUN servers, so
> the naked Ping can be replaced by a STUN connectivity check.  The nice thing
> about STUN is that the support for anycast is already there, as a STUN server
> running on an anycast address will respond with a 300 Try Alternate with an
> ALTERNATE-SERVER attribute containing the IP address of the non-anycast node.
> 
> So the whole problem can be solved by just saying in -base that any connection
> to the bootstrap servers must start with a STUN connectivity check.  The first
> IP address to successfully respond (i.e. after processing the 300), is the one
> where the DTLS/TLS connection must be established to start sending the RELOAD
> messages.
> 
> 
> 
> [1] https://www.ietf.org/proceedings/84/minutes/minutes-84-p2psip
> [2] https://www.ietf.org/proceedings/82/minutes/minutes-82-p2psip
> 
> - -- 
> Marc Petit-Huguenin
> Email: [email-masked]
> Blog: http://blog.marc.petit-huguenin.org
> Profile: http://www.linkedin.com/in/petithug
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.12 (GNU/Linux)
> 
> iQIcBAEBCAAGBQJQW0RwAAoJECnERZXWan7EZRsP/jDXiBZQBHBJAD8qP2CFp7a7
> wQ5xF5Ms5F1NCyciC5q6ufYs3Yj8ipwQ1cx9vJAJ6E72j1f4ZLMiNxy9Dr750peD
> kK/KAvj5cSMgpp56al+G4J3pdnrIPwx/trRncdX3OAsq8Rtn2GO8lyMFw7RdHK/i
> wrnZCrSa8e2a2jtt/0Ip7xpnaazgkQKn8x9McoQMtPuy2mrUrmZX2uPvLKnc6UQ+
> zl0OfI62PKMv/IryGU9fRIx2vVGRMdu1AgXoIP0jtDnkUo19jcWe3/7ZWzOFeCpT
> tQaIHhDmSyOZ4EVhYTHHLTT42O0BsO/fdgwKT3PvJJQCEPRi16S36oQzS33tWD6h
> bEaGFKeC9QotWq2FHaH/38Cqr+nuIB4azBEpEEwErzWGiy0lPSWiL8sJ7TaTSugJ
> NS5ocDUngf8tZ/3o+sGPypLRMW71BSHvFkWmJ36HuA4Yzg7M68YZto/kw3RdW/J8
> G02COfsf2w0131QPoRUQLQgSOHz6ZP7aiwuqrmKyRhxp1jgaVW1iFY0mOzJI+Nw7
> omRr0Htw1BghfoBkEGWHejH6cymB2ld1+vvwSHgMryC4rLuPrdLBiBf6isFp0xLi
> FKiRVYL3pb4rNrzu2KjaiE6Wv6FhR/Ysdo+XsbxH+jRcfSXLz3i5B65O+wcr0Alj
> Eu1SX15X9nY+FAC2DmjZ
> =x01n
> -----END PGP SIGNATURE-----
> _______________________________________________
> P2PSIP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/p2psip

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Sun, 04 Nov 2012 13:16:01 -0800

On 11/04/2012 08:23 AM, Cullen Jennings wrote:
> 
> I like your solution but given that base is deployable without this, I
> wonder if you could just write this up in a separate draft that was an
> extension to base?

Sure, in this case remove all the stuff in -base related to anycast/multicast
and broadcast (as agreed in Vancouver), and I'll start working on a draft with
the bits removed from -base, plus my proposal.  I may even be able to do that
and publish before the P2PSIP WG meeting.

As the new draft will take text from -base, what authors from -base should I
add to the new draft?

Thanks.

> multicast/anycast/broadcast in the RELOAD spec, following a discussion
> back in Taipei about problems for supporting anycast.
> 
> I thought a bit more about the anycast problem, and I found a solution to 
> this problem that is simple and so that would permit to keep the text in 
> -base.
> 
>  anycast address because the real destination can change at any time, and 
> that would break DTLS.  That can be solved by adding the IP address of a 
> bootstrap node not running on the anycast address in the PingResponse, but 
> unfortunately this is not a compatible change.  There is other problems
> with this approach, related to the fact that the Ping must be sent without
> DTLS (naked Ping).
> 
> But, as per -base section 6.5.1.4, all RELOAD nodes are also STUN servers, 
> so the naked Ping can be replaced by a STUN connectivity check.  The nice 
> thing about STUN is that the support for anycast is already there, as a
> STUN server running on an anycast address will respond with a 300 Try
> Alternate with an ALTERNATE-SERVER attribute containing the IP address of
> the non-anycast node.
> 
> So the whole problem can be solved by just saying in -base that any 
> connection to the bootstrap servers must start with a STUN connectivity 
> check.  The first IP address to successfully respond (i.e. after
> processing the 300), is the one where the DTLS/TLS connection must be
> established to start sending the RELOAD messages.
> 
> 
> 
> [1] https://www.ietf.org/proceedings/84/minutes/minutes-84-p2psip [2] 
> https://www.ietf.org/proceedings/82/minutes/minutes-82-p2psip
> 
>> _______________________________________________ P2PSIP mailing list 
>> [email-masked] https://www.ietf.org/mailman/listinfo/p2psip
> 

- -- 
Marc Petit-Huguenin
Personal email: [email-masked]
Professional email: [email-masked]
Blog: http://blog.marc.petit-huguenin.org

---

From: Cullen Jennings <[email-masked]>
Date: Sun, 4 Nov 2012 19:10:16 -0500

> As the new draft will take text from -base, what authors from -base should I

I don't think you need to take any of them. You might put in acknowledgment that explained the original source….

> iQIcBAEBCAAGBQJQltsPAAoJECnERZXWan7EK5oQALoq1+ROmxiOlaBMGw2/E6jy
> ZDOPtblDCrubxPyazQypPphkD/zDkqsVwYjXEUonbo8C2RCwUhjJLPwYBdp7hiZf
> PPsYxBDrSn3rGe8rf9A1S+PaKmcbExrbZhJghycW84qN8T6tJREDqD8Wh37eS/Tk
> jyycIYOkLHfttL1EA78Q/tj9ogXwdBqOH5AAnlfjn6StmaLZ/2Ro1TWwoGMTR8Pn
> VBowlw3JpwsGxOc5EbDO9UsKsDTVw3cLOl3fZHWh+mFhf/aCgfipzXaVNlb4K4Gk
> vK19H2y5Jhf+T7TdJVsz5qmtJBmXszDDt+5mTJwWKO8qSv+/yR7iczzItFtrmFnE
> 6ifEtEFCrEVsoNlYdeZtMJKCo+LTdEPSh3vlg+c2NOgZ/mJsAJYYz8bf1tQ5fA1C
> 3o0lP+hPbHqTTrfKNY/SM11IDygNMhhwXvLngNC+0uC5rhwZgNGOUZJDi2mIHTg+
> ZdfPJ8DU77TmPN1yJZeVRvBj+azICD/9qSBT69Hs+HkE/9MGnQ4pojgNRtWUEqb0
> Xi8HWPcQpCAzom3wq1zp8HDK7G3w1ql+wjC4/oN+caohcbXsJRWFMVLSklPAH5Vw
> eCd2U5vmSSFA74Md3I8eYrkcLLsvIgcuzFjhQt8X+GAxxNgLZiW4z3o99HogHyQe
> 1/bwYxOivTdeuCP296pl
> =UK5L