Date: Tue, 06 Jun 2017 08:10:13 -0700
From: =?UTF-8?B?SsSBbmlz?= <notifications@github.com>
Reply-To: quicwg/base-drafts
 <reply+0166e4abe9e989e4828953bdeb9b28d48c22f1050a6999a592cf00000001154e87d492a169ce0df019e0@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/pull/589/c306517012@github.com>
In-Reply-To: <quicwg/base-drafts/pull/589@github.com>
References: <quicwg/base-drafts/pull/589@github.com>
Subject: Re: [quicwg/base-drafts] Move connection ID change to only Server
 Cleartext (#589)
Mime-Version: 1.0
Content-Type: multipart/alternative;
 boundary="--==_mimepart_5936c5d55fe_63ed3ffbed29fc388783";
 charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: list
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/PSHyL6u1OVVPo70t-KCPEg1aB6I>

----==_mimepart_5936c5d55fe_63ed3ffbed29fc388783
Content-Type: text/plain;
 charset=UTF-8
Content-Transfer-Encoding: 7bit

Well then I would like to propose to reconsider that. Is there any reason why Server Stateless Retry couldn't change CID?

1) Firstly, in my opininon server without using Server Stateless Retry (without verifying src address/port) is simply asking to be DOS attacked. I could fill server's RAM with Raspberry Pi by simply spoofing src address. Thats why I am talking about situation where that check is enabled.

2) Secondly, imageine that you want to use CID for load balancing your clients. In current solution you would have to support accepting TLS handshake on all backends and when initial request is validated the partial TLS and QUIC state must be serialized and somehow transported to decided loadbalanced server (with the new CID) - and thats not easy AT ALL. I think, that this can be solved by simply returning new CID in Server Stateless Retry without doing any work or state transportation on backend.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/589#issuecomment-306517012
----==_mimepart_5936c5d55fe_63ed3ffbed29fc388783
Content-Type: text/html;
 charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p>Well then I would like to propose to reconsider that. Is there any reaso=
n why Server Stateless Retry couldn't change CID?</p>
<ol>
<li>
<p>Firstly, in my opininon server without using Server Stateless Retry (wit=
hout verifying src address/port) is simply asking to be DOS attacked. I cou=
ld fill server's RAM with Raspberry Pi by simply spoofing src address. That=
s why I am talking about situation where that check is enabled.</p>
</li>
<li>
<p>Secondly, imageine that you want to use CID for load balancing your clie=
nts. In current solution you would have to support accepting TLS handshake =
on all backends and when initial request is validated the partial TLS and Q=
UIC state must be serialized and somehow transported to decided loadbalance=
d server (with the new CID) - and thats not easy AT ALL. I think, that this=
 can be solved by simply returning new CID in Server Stateless Retry withou=
t doing any work or state transportation on backend.</p>
</li>
</ol>

<p style=3D"font-size:small;-webkit-text-size-adjust:none;color:#666;">&mda=
sh;<br />You are receiving this because you are subscribed to this thread.<=
br />Reply to this email directly, <a href=3D"https://github.com/quicwg/bas=
e-drafts/pull/589#issuecomment-306517012">view it on GitHub</a>, or <a href=
=3D"https://github.com/notifications/unsubscribe-auth/AWbkq3h3esEu8oNLBrz5p=
QLsPTnByFvyks5sBWvUgaJpZM4NxHYp">mute the thread</a>.<img alt=3D"" height=
=3D"1" src=3D"https://github.com/notifications/beacon/AWbkq8PtA4Vl38pT2iuKK=
RzAtwb-jNOgks5sBWvUgaJpZM4NxHYp.gif" width=3D"1" /></p>
<div itemscope itemtype=3D"http://schema.org/EmailMessage">
<div itemprop=3D"action" itemscope itemtype=3D"http://schema.org/ViewAction=
">
  <link itemprop=3D"url" href=3D"https://github.com/quicwg/base-drafts/pull=
/589#issuecomment-306517012"></link>
  <meta itemprop=3D"name" content=3D"View Pull Request"></meta>
</div>
<meta itemprop=3D"description" content=3D"View this Pull Request on GitHub"=
></meta>
</div>

<script type=3D"application/json" data-scope=3D"inboxmarkup">{"api_version"=
:"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c55493e4bb","name":"Gi=
tHub"},"entity":{"external_key":"github/quicwg/base-drafts","title":"quicwg=
/base-drafts","subtitle":"GitHub repository","main_image_url":"https://clou=
d.githubusercontent.com/assets/143418/17495839/a5054eac-5d88-11e6-95fc-7290=
892c7bb5.png","avatar_image_url":"https://cloud.githubusercontent.com/asset=
s/143418/15842166/7c72db34-2c0b-11e6-9aed-b52498112777.png","action":{"name=
":"Open in GitHub","url":"https://github.com/quicwg/base-drafts"}},"updates=
":{"snippets":[{"icon":"PERSON","message":"@chocis in #589: Well then I wou=
ld like to propose to reconsider that. Is there any reason why Server State=
less Retry couldn't change CID?\r\n\r\n1) Firstly, in my opininon server wi=
thout using Server Stateless Retry (without verifying src address/port) is =
simply asking to be DOS attacked. I could fill server's RAM with Raspberry =
Pi by simply spoofing src address. Thats why I am talking about situation w=
here that check is enabled.\r\n\r\n2) Secondly, imageine that you want to u=
se CID for load balancing your clients. In current solution you would have =
to support accepting TLS handshake on all backends and when initial request=
 is validated the partial TLS and QUIC state must be serialized and somehow=
 transported to decided loadbalanced server (with the new CID) - and thats =
not easy AT ALL. I think, that this can be solved by simply returning new C=
ID in Server Stateless Retry without doing any work or state transportation=
 on backend."}],"action":{"name":"View Pull Request","url":"https://github.=
com/quicwg/base-drafts/pull/589#issuecomment-306517012"}}}</script>=

----==_mimepart_5936c5d55fe_63ed3ffbed29fc388783--