RE: Using Long Header packets for PMTUD probes

"Lubashev, Igor" <ilubashe@akamai.com> Sat, 30 June 2018 13:01 UTC

Return-Path: <ilubashe@akamai.com>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ED561310C6 for <quic@ietfa.amsl.com>; Sat, 30 Jun 2018 06:01:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.72
X-Spam-Level:
X-Spam-Status: No, score=-0.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ednXlqVse8iz for <quic@ietfa.amsl.com>; Sat, 30 Jun 2018 06:01:54 -0700 (PDT)
Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E448A130ECA for <quic@ietf.org>; Sat, 30 Jun 2018 06:01:52 -0700 (PDT)
Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.22/8.16.0.22) with SMTP id w5UCknp3017025; Sat, 30 Jun 2018 14:01:44 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=KeJbPkJbawRnzJ3WDqdbIx08xXKx245GvELrJHLB8+c=; b=Y+TXYt3yrq4qIRt+JEU+7mTYVfrpnhmdGZKnM4V7MU1LlLORKcflOikkVRU7IjStkleR LOdvx5T5hcqD9hhndb8ck+DDB1ASg3xB01eFlKwUXQzj6xskwsmyElizFWJx0KeY0rqv UrwAv+7ZT+3pQeykQmdTBt+75W9S7ws3A5085vSHJzvbw0xuk2wt8tMvZyc1G6wP8ryL 99N025meXSPXfBtbjE9sWXzZT+0rfU2MlSU35kcq9FHbwyiBCdwFi+7P9+CQ0vzxD+BI 2gbNDXAyhYVzAXYI6a/ZgJhQCu28FSTLfaVVjzJ+KxmfIiPPiKmI8juRqzxow9ZkwGXb nA==
Received: from prod-mail-ppoint4 (a96-6-114-87.deploy.static.akamaitechnologies.com [96.6.114.87] (may be forged)) by m0050102.ppops.net-00190b01. with ESMTP id 2jx225101b-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 30 Jun 2018 14:01:44 +0100
Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w5UD12lU015264; Sat, 30 Jun 2018 09:01:43 -0400
Received: from email.msg.corp.akamai.com ([172.27.27.25]) by prod-mail-ppoint4.akamai.com with ESMTP id 2jx56vgm91-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Sat, 30 Jun 2018 09:01:43 -0400
Received: from USTX2EX-DAG1MB5.msg.corp.akamai.com (172.27.27.105) by ustx2ex-dag1mb2.msg.corp.akamai.com (172.27.27.102) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Sat, 30 Jun 2018 08:01:42 -0500
Received: from USTX2EX-DAG1MB5.msg.corp.akamai.com ([172.27.27.105]) by ustx2ex-dag1mb5.msg.corp.akamai.com ([172.27.27.105]) with mapi id 15.00.1365.000; Sat, 30 Jun 2018 08:01:42 -0500
From: "Lubashev, Igor" <ilubashe@akamai.com>
To: "huitema@huitema.net" <huitema@huitema.net>, "mikkelfj@gmail.com" <mikkelfj@gmail.com>, "kazuhooku@gmail.com" <kazuhooku@gmail.com>
CC: "quic@ietf.org" <quic@ietf.org>
Subject: RE: Using Long Header packets for PMTUD probes
Thread-Topic: Using Long Header packets for PMTUD probes
Thread-Index: AdQP6f+k+GmPnfLgQ7evczPwCZupawAR9GSAAANhAwD//9UbB4AAcegAgAAfTAM=
Date: Sat, 30 Jun 2018 13:01:41 +0000
Message-ID: <df2ad840e4f34f00a3d8867c76ad287a@ustx2ex-dag1mb5.msg.corp.akamai.com>
References: <178f3f4cc96e4f1ab90595fd2530c4b3@ustx2ex-dag1mb5.msg.corp.akamai.com> <97fa8d20-a3d8-8926-e6d3-42afa96d5fe1@huitema.net> <CANatvzwtVuBJ6LMrE7-tAbPjKz=JTG8Gb_KnWwtD+uDOdT_zCQ@mail.gmail.com> <a2ad6b9fde0d40f483532b4b32160015@ustx2ex-dag1mb5.msg.corp.akamai.com>, <CAN1APdfccODDNsVMKT-73hGOicU7stX0pwukswzZ8OMH4k9sTw@mail.gmail.com>
In-Reply-To: <CAN1APdfccODDNsVMKT-73hGOicU7stX0pwukswzZ8OMH4k9sTw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
Content-Type: multipart/alternative; boundary="_000_df2ad840e4f34f00a3d8867c76ad287austx2exdag1mb5msgcorpak_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-06-30_04:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1806300152
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-06-30_04:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1806300151
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/irsHOZ0z2GuFY-rTS1ngobGr9bM>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 30 Jun 2018 13:01:58 -0000

I can see the log pollution argument. When a packet is dropped, people often want to be able to say why. At the minimum, it would pollute the meaning of some counter -- it would increment for both intentionally invalid and unintentionally invalid long header packets, making it impossible to tell the two apart. Hence, a specific "Generic 1-rtt long header" type feels preferable.

I would not worry about DDoS with such packets. They still require a valid CID. It is simpler and more effective to DDoS with something that tries to elicit a reply and not just a drop (and does not contain a valid CID).

-----Original Message-----
From: Mikkel Fahnøe Jørgensen [mikkelfj@gmail.com]
Received: Saturday, 30 Jun 2018, 2:09AM
To: kazuhooku@gmail.com [kazuhooku@gmail.com] Lubashev, Igor [ilubashe@akamai.com] huitema@huitema.net [huitema@huitema.net]
CC: quic@ietf.org [quic@ietf.org]
Subject: RE: Using Long Header packets for PMTUD probes

Sending explicit invalid headers would pollute logs and make it more difficult to track down problems.

I'd assume probes are infrequent, but otherwise they might also tie up resources and prevent (by the nature of greasing) dropping packets in DDoS scenario, or black listing addresses with bad content for a while.

Mikkel


On 30 June 2018 at 06.22.36, Lubashev, Igor (ilubashe=40akamai.com@dmarc.ietf.org<mailto:ilubashe=40akamai.com@dmarc.ietf.org>) wrote:

I like the idea of greasing. I also like the idea of using 1-rtt headers to make stateless reset work.

I would prefer not to use known packet types, especially "INITIAL" and "0-RTT", because that will confuse stateless load balancers (these packet types are expected to carry random destination CID). But RETRY and HANDSHAKE seem fine. A special "Generic 0-rtt" type would work, too.

- Igor

-----Original Message-----
From: Kazuho Oku [kazuhooku@gmail.com<mailto:kazuhooku@gmail.com>]
Received: Friday, 29 Jun 2018, 9:55PM
To: Christian Huitema [huitema@huitema.net<mailto:huitema@huitema.net>]
CC: Lubashev, Igor [ilubashe@akamai.com<mailto:ilubashe@akamai.com>]; IETF QUIC WG [quic@ietf.org<mailto:quic@ietf.org>]
Subject: Re: Using Long Header packets for PMTUD probes

2018-06-30 9:18 GMT+09:00 Christian Huitema <huitema@huitema.net<mailto:huitema@huitema.net>>:
> On 6/29/2018 2:00 PM, Lubashev, Igor wrote:
>
> We talked briefly in Kista about the possibility of using Long Header
> packets for PMTUD probes.  See Issue 1243
> (https://github.com/quicwg/base-drafts/issues/1243<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_quicwg_base-2Ddrafts_issues_1243&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Djn3bQ5uNJDPM_2skfL3rW1tzcIxyjUZdn_m55KPmlo&m=X-NJO04I-P6QgduCa5-jWI7QC_mILlYpjmLP5p-T-X0&s=v9GHLI2TXgBuQxsk21bjDeWPYewcHxL0nEgn_HtMsXk&e=>) for context.  Briefly,
> load balancers that use server CID need that server CID to route ICMPv6
> packets back to the server doing PMTUD.
>
>
>
> @'Kazuho Oku' suggested using the new packet coalescing functionality by
> sending an invalid long-header packet and coalescing it with a valid
> short-header packet.  This would have to work, if one follows the current
> spec strictly.  This is definitely a hack, however.
>
>
>
> I would like to come up with something that is not a hack, does not require
> sending deliberately invalid packets, but also not to complicate the design
> with the need to care about key phase and whatever else one wants to put in
> the short-header in the future.
>
>
>
> What do people think about a new "0x7B - PMTU Probe" long header packet
> type?
>
> A packet of that type would just be a bare minimum long header packet per
> Invariants (nothing after source CID), and its only purpose would be to be
> coalesced with other QUIC packets.
>
>
> My personal inclination is to just ignore ICMP, and thus not have to deal
> with related attacks. My limited experience so far is that active PMTU
> discovery succeeds after just a couple of probes.
>
> In any case, I would rather not have a specific "PMTU Probe" long header --
> I would rather not disclose to middleboxes that the node is engaged in
> PMTUD. But I could see the point of a generic "1-RTT" long header. It could
> help make stateless reset work. And it could be sent proactively, say every
> few RTT, as a form of greasing.

+1

Use of an invalid long header packet is a form of greasing. There is
no point in explicitly disclosing the fact that an endpoint is engaged
in a PMTUD.

Hence I continue to believe that using an invalid long header packet
for the purpose would be fine.

It *could* be a Retry packet as Ian suggests, but it can be anything
else. And even if it is not a Retry packet, it does not need to be
encrypted or carry the AEAD tag, because nobody is going to decrypt it
(for example a Handshake packet with a zero-length payload is just an
ordinary form of an invalid packet).

> -- Christian Huitema
>
>
>



--
Kazuho Oku