Subject: Re: [hybi] hybi Digest, Vol 51, Issue 14

From: Scott Morgan <[email-masked]>
Date: Tue, 28 May 2013 14:44:07 -0500

Hi,

    Also what will happen if multiple to the multiplexed ws if one of two
browser tabs calls close on the ws connection?
   Does the other tab force keep the ws connection open?
   Does the other tab have to auto recover and reopen the connection?

Sorry if I missed this somewhere in the drafts.
Just my 2cents.

   It's important for a attempt to block browser ip address spoofing on the
first ws connection in a the following use case;

1 Browser connects to a wss server
2 User does some authentication (ie user id, password)
3 wss server does authentication using user id, password and ip address
(for either some privileges or as a additional authentication parameter for
a success fail style authentication)
4 after successful auth message at the browser an the wss connection is
closed
 and a different wss is opened on the same port with a different path in
the url
5 The wss server only allows the different wss connection to open if there
is a http session from the original wss connection from the same ip address
of the first connection.

Not that this is a fool proof solution to ip address spoofing, but it would
at least provide some level of ip address spoofing support (as the spoofer
would need to know that it had to spoof twice).  If the connection stayed
open, the original spoof would remain in effect and this sort of attempt to
block ip address spoofing would be rendered completely in-effective.

Cheers,
Scott

On Tue, May 28, 2013 at 2:00 PM, <[email-masked]> wrote:

> If you have received this digest without all the individual message
> attachments you will need to update your digest options in your list
> subscription.  To do so, go to
>
> https://www.ietf.org/mailman/listinfo/hybi
>
> Click the 'Unsubscribe or edit options' button, log in, and set "Get
> MIME or Plain Text Digests?" to MIME.  You can set this option
> globally for all the list digests you receive at this point.
>
>
>
> Send hybi mailing list submissions to
>         [email-masked]
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://www.ietf.org/mailman/listinfo/hybi
> or, via email, send a message with subject or body 'help' to
>         [email-masked]
>
> You can reach the person managing the list at
>         [email-masked]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of hybi digest..."
>
>
> Today's Topics:
>
>    1. Re: Call for interest: multiplexing dedicated for WebSocket
>       (Takeshi Yoshino)
>    2. Re: I-D Action: draft-ietf-hybi-permessage-compression-09.txt
>       (Takeshi Yoshino)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 28 May 2013 15:22:39 +0900
> From: Takeshi Yoshino <[email-masked]>
> To: Tobias Oberstein <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>
> Subject: Re: [hybi] Call for interest: multiplexing dedicated for
>         WebSocket
> Message-ID:
>         <
> [email-masked]>
> Content-Type: text/plain; charset="iso-8859-1"
>
> On Mon, May 27, 2013 at 8:59 PM, Tobias Oberstein <
> [email-masked]> wrote:
>
> > >>However, when running _different_ apps on the same device connecting to
> > the same origin,
> >
> > >You meant same ws:// address?
> >
> > Yes, sorry not origin.
> >
> > I had a look into the MUX RFC again .. couldn't find anser to the
> > following (may have missed sth):
> >
>
> It's not yet specified.
>
>
> > What WS addresses would be eligible to be multiplexed over a single WS
> > connection?
> >
> > a) ws://somehost.com:999/
> > b) ws://somehost.com:999/foo
> > c) ws://somehost.com:999/bar
> >
> > d) wss://somehost.com:999/
> > e) wss://somehost.com:999/foo
> > f) wss://somehost.com:999/bar
> >
> > All of a) - f) are to the same target IP:port and hence could share the
> > same TCP.
> >
>
> I think it's fine.
>
>
> > However, d) - f) use wss, and hence have a TLS handshake right after TCP
> > establishment.
> >
>
> Right unless TLS parameters differ (such as client cert) between paths.
>
> See also SPDY's CREDENTIAL frame.
>
> https://github.com/grmocg/SPDY-Specification/blob/gh-pages/draft-mbelshe-spdy-00.txt
>
>
> > So d) - f) cannot be multiplexed over the same physical WS as a) - c)?
> >
>
> It's fine and up to the client.
>
>
> > Or can an implementation just "silently" transport a)-c) also over wss,
> > and hence multiplex all of a) - f) over 1 physical WS?
> >
> > Lastly, a)-c) are to the same target IP:port and also WS schema (ws, not
> > wss) - and hence can be multiplexed over 1 physical WS even though they
> are
> > to different URL paths?
> >
> > IOW: in the context of ws-mux, what is "same target"?
>
>
> Basically ip:port. We don't need to isolate them based on hostname, I
> believe, unless it's required by some security/privacy policy.
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://www.ietf.org/mail-archive/web/hybi/attachments/20130528/0180f4a2/attachment.html
> >
>
> ------------------------------
>
> Message: 2
> Date: Tue, 28 May 2013 16:19:18 +0900
> From: Takeshi Yoshino <[email-masked]>
> To: "[email-masked]" <[email-masked]>
> Subject: Re: [hybi] I-D Action:
>         draft-ietf-hybi-permessage-compression-09.txt
> Message-ID:
>         <CAH9hSJYa8QA9VkOwS6GEr0+8iJcnQcpMy3X_fKwGQOuJRr=
> [email-masked]>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Hi all,
>
> Please post your opinions and experience (implemented, faced any
> difficulties, found issues, etc.).
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://www.ietf.org/mail-archive/web/hybi/attachments/20130528/74b6e651/attachment.htm
> >
>
> ------------------------------
>
> _______________________________________________
> hybi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hybi
>
>
> End of hybi Digest, Vol 51, Issue 14
> ************************************
>

---

From: Takeshi Yoshino <[email-masked]>
Date: Wed, 29 May 2013 12:36:44 +0900

>    Does the other tab have to auto recover and reopen the connection?

close() call on a WebSocket instance that is multiplexed in network stack
should result in close of the logical channel used by the WebSocket
instance. Not close on the physical WebSocket connection. Once the last
logical connection is closed, the network stack may start closing the
physical connection. It can be also delayed.
http://tools.ietf.org/html/draft-ietf-hybi-websocket-multiplexing-10#section-15
is
the section discussing that.

>    It's important for a attempt to block browser ip address spoofing on
> the first ws connection in a the following use case;
>
>
Could you elaborate?

> (for either some privileges or as a additional authentication parameter
> for a success fail style authentication)
>

That is that only access from some IP address X will have some high
privilege?

> is a http session from the original wss connection from the same ip address

Does the server get a session parameter over the new connection and also
check the source IP address? Or the server here just checks if there was
successful authentication on some prior connection with the same IP address
as the new one?

>
> Not that this is a fool proof solution to ip address spoofing, but it
> would at least provide some level of ip address spoofing support (as the
> spoofer would need to know that it had to spoof twice).  If the connection
> stayed open, the original spoof would remain in effect and this sort of
> attempt to block ip address spoofing would be rendered completely
> in-effective.
>