On Apr 3, 2008, at 6:43 AM, Philip Matthews wrote:
>
> On Thu, 3-Apr-08, at 06:54 , Cullen Jennings wrote:
> >
> > On Apr 2, 2008, at 7:22 PM, Philip Matthews wrote:
> >> At the last BEHAVE meeting, it was suggested that one use of
> >> ALTERNATE-
> >> SERVER was to support anycast discovery of TURN servers. I have  
> been
> >> doing some inquiries, and it seems that there might be a problem  
> with
> >> this idea.
> >>
> >> The way I had been thinking this would work is that a client would
> >> send an Allocate request to an anycast address, and would receive  
> an
> >> error response back with an error code of 300 Try Alternative and  
> an
> >> ALTERNATE-SERVER attribute giving the unicast address of the server
> >> to
> >> contact.
> >>
> >> The problem is that it seems there is no guarantee that two
> >> consecutive packets will be delivered to the same anycast server.  
> The
> >> only thing that is guaranteed is a single round-trip exchange[1].
> >> This
> >> means that the above idea does not work because:
> >> a) It is not possible to contact an anycast TURN server using TCP  
> or
> >> TLS over TCP, since the handshake will not necessarily complete  
> with
> >> the same server.
> >> b) It is also not possible to contact an anycast TURN server using
> >> UDP, since STUN says that an ALTERNATE-SERVER reply must be
> >> authenticated, and authentication in TURN requires a 4-packet
> >> exchange.
> >>
> >> So this straight-forward method of doing anycast lookup in TURN  
> does
> >> not seem to work.
> >>
> >> There are probably ways to fix this by changing how ALTENATE-SERVER
> >> works in TURN, but I am currently inclined to forget about anycast
> >> for
> >> TURN right now, and let someone add it later.
> >>
> >> Comments?
> >>
> > Sure, what you are proposing here won't work for the reasons you
> > point out. I don't know when the WG decided the ALTERNATIVE-ERVER
> > reply MUST be authenticated but that seems like it is not going to
> > work for anycast.
>
> Sorry. I should have provided a reference. draft-ietf-
> behave-3489bis-15, section 11 says:
>
> 11.  ALTERNATE-SERVER Mechanism
>
>     This section describes a mechanism in STUN that allows a server to
>     redirect a client to another server.  This extension is optional,
> and
>     a usage must define if and when this extension is used.  To  
> prevent
>     denial-of-service attacks, this extension MUST only be used in
>     situations where the client and server are using an authentication
>     and message-integrity mechanism.
>
>     A server using this extension redirects a client to another server
> by
>     replying to a request message with an error response message  
> with an
>     error code of 300 (Try Alternate).  The server MUST include a
>     ALTERNATE-SERVER attribute in the error response.  The error
> response
>     message MUST be authenticated, which in practice means the request
>     message must have passed the authentication checks.
>
>     [Rest of section omitted]
>
>

right - thanks

> > There are more than a few things wrong with this - for one I suspect
> > the authentication you are talking about is for the server to
> > authenticate the client not for the client to authenticate the
> > server. As an alternative you might want to consider is something
> > like what I had previously email you - I'm sure lots of other ways
> > would work too and I don't really care which way we do it. No doubt
> > the thing I emailed has some issues that would need to be worked out
> > but I think it is closer to working.
> >
> > On Apr 2, 2008, at 3:41 PM, Cullen Jennings wrote:
> >>
> >>
> >> 1) client is configured with TURN server of turn.example.com
> >>
> >> 2) client does an SRV lookup and finds there is no TCP service but
> >> there is a UDP service at 1.1.1.1
> >>
> >> 3) client sends an UDP packet to 1.1.1.1 which happens to be an
> >> anycast IP.
> >>
> >> 4) Some server gets this and responds with a redirect to 2.2.2.2
> >> along with info to use TLS. The address 2.2.2.2 is not an anycast
> >> address but goes to a single machine with a TURN server
> >>
> >> 5) client does TLS to 2.2.2.2. Server presents certificate with
> >> name turn.example.com
> >>
> >> 6) client check certificate matches the name that it has in it's
> >> config.
> >>
> >> This approach is susceptible to being DOSed by a well timed
> >> response to the UDP request to 1.1.1.1 but seemed like a risk we
> >> were willing to live with. Presumably some secret material would be
> >> copied from request in step 3 to the response in step 4 to force
> >> the attacker to be on-path.
> >
> >
> > If the client doesn't care about server authentication, then it can
> > ignore TLS and do much the same with just UDP.
> >
> > It's going to be very difficult to add something like this in later
> > so I would argue we should deal with having at least enough
> > placeholders in the base draft that we can add it later - to do this
> > we will likely need to figure it out well enough that we should just
> > add it to the base draft instead of trying to do it as an extension.
> >
> > Cullen <with my individual contributor hat on>
>
> This works if the client can contact the server using both UDP and
> TCP. As you know, we are separately discussing the case of a client
> that can only contact TURN servers using TCP -- this is the proposed
> justification for TCP transport for a UDP allocation. If we decide to
> keep TCP transport for a UDP allocation (and right now, I am seeing
> more support for keeping it than dropping it -- but we will discuss
> this next week on the conf call), then I have a problem with something
> like this as the proposed anycast solution.
>
> I will note that there are a couple of ways to achieve something very
> similar to this without using anycast. The first option is that
> 1.1.1.1 is not an anycast address, but is a unicast address of a TURN
> server that doesn't actually accept allocations, but always redirects
> clients to other servers (using ALTERNATE-SERVER). The second is to
> use DNS to direct the client to a closer or otherwise appropriate
> server.
>
The point of the anycast is not to just spread stuff over multiple  
servers - a DNS A record could do that. The point is to solve in some  
way the "close" problem where the client ends up using a TURN server  
that is topologically close to the client. Anycast is a one appealing  
way to address that. What you are proposing does not seem to address  
the issues of getting to a TURN server that is topologically close to  
the client.
>
>
> - Philip
>
>

_______________________________________________
Behave mailing list
Behave@ietf.org
https://www.ietf.org/mailman/listinfo/behave