Re: [Softwires] MAP-T issue - UDP packets with zero checksum

"Gottlieb, Jordan J" <Jordan.Gottlieb@charter.com> Mon, 07 November 2022 16:05 UTC

Return-Path: <Jordan.Gottlieb@charter.com>
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71ED9C15259F for <softwires@ietfa.amsl.com>; Mon, 7 Nov 2022 08:05:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.003
X-Spam-Level:
X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=charter.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hkBTHPdKfihQ for <softwires@ietfa.amsl.com>; Mon, 7 Nov 2022 08:05:09 -0800 (PST)
Received: from mail.chartercom.com (nce.mail.chartercom.com [142.136.234.138]) (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 72616C15256D for <softwires@ietf.org>; Mon, 7 Nov 2022 08:05:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=charter.com; i=@charter.com; q=dns/txt; s=1; t=1667837109; x=1699373109; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=YtI2JWemFc5UqVMSZzYSYM8glbYZQPzRjM+xq+XIFHI=; b=PMSiZPMtM9Iw7FxD0gE1JTLWX4jq/4HdlUn1H74MzVDv4OPK/MxBq6b0 U7Pegyw5aBF/fCECVEvZjAJnZlRQ91qnMiE9rK7v6zaKFjHS7tVPxM2T+ XdSvAgG6UIojKulvQuK/sE8acPvwGVbROmy2AQaupgSbhr/jiBCJo53tY sOPZc02K4+wUsHuYXNodAtGDrrwW/aAvqAYz840tbeZgmyqjbtCiDQ6F9 htsBrpL9bPkPm2ICIJaBvarnUIS/6Uh9fOYCHbr6vyUD/4xAmqALouVfT gyc9RVhn4bDMgT4HFQePyAERq37ny3+CXhl1goFO13XBhfiEUbUViH8aC A==;
X-Ironport-Dmarc-Check-Result: validskip
IronPort-SDR: vDo4vAPXzUY1mQZ4dXfw7peB9ym2ZBKngwlulQ5D1Gn7EcsOxwn1JLgq5LQogT8NqALhiZkule UpkGQ9CivZ+w==
X-IronPort-AV: E=Sophos;i="5.96,145,1665464400"; d="png'150?scan'150,208,217,150";a="255531935"
Received: from ncemexgp038.corp.chartercom.com ([142.136.234.53]) by mail.chartercom.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA384; 07 Nov 2022 10:05:07 -0600
Received: from ncemexgp037.CORP.CHARTERCOM.COM (2002:8e88:ea34::8e88:ea34) by ncemexgp038.CORP.CHARTERCOM.com (2002:8e88:ea35::8e88:ea35) with Microsoft SMTP Server (TLS) id 15.0.1497.36; Mon, 7 Nov 2022 16:05:06 +0000
Received: from ncemexgp037.CORP.CHARTERCOM.COM ([fe80::39af:a3ee:abce:8b46]) by ncemexgp037.CORP.CHARTERCOM.com ([fe80::39af:a3ee:abce:8b46%20]) with mapi id 15.00.1497.036; Mon, 7 Nov 2022 16:05:06 +0000
From: "Gottlieb, Jordan J" <Jordan.Gottlieb@charter.com>
To: "Overcash, Michael (CCI-Atlanta)" <michael.overcash@cox.com>, "Rajiv Asati (rajiva)" <rajiva@cisco.com>, "Poscic, Kristian (Nokia - US)" <kristian.poscic@nokia.com>
CC: "softwires@ietf.org" <softwires@ietf.org>
Thread-Topic: [Softwires] MAP-T issue - UDP packets with zero checksum
Thread-Index: AdjwUUmY0/et/yqoSIW1ZoK7abCNIwAFSeXgAACacrAAASIHjwABARqAAAGxtOAABsB5TgCJM0vAAAKmuFA=
Date: Mon, 07 Nov 2022 16:05:06 +0000
Message-ID: <3ad9cf3747ff4423875ecf1943b0961d@ncemexgp037.CORP.CHARTERCOM.com>
References: <BN0PR01MB6845514B7AA311E72CF066DD9F3B9@BN0PR01MB6845.prod.exchangelabs.com> <e574a7b999c246ea9391dc6399213c56@ncemexgp037.CORP.CHARTERCOM.com> <SA2PR08MB6521E712618525A7A703E846ED3B9@SA2PR08MB6521.namprd08.prod.outlook.com> <A682B9A1-2C05-4091-8D48-DF57C7EE5F79@cisco.com> <d71bdf57379b4d8f9715c91e24a8930b@ncemexgp037.CORP.CHARTERCOM.com>, <BN0PR01MB6845B86947CE0F194C36FD7E9F3B9@BN0PR01MB6845.prod.exchangelabs.com> <1667597316329.96993@charter.com> <BN0PR01MB68453E68300E91AC94DE3E8B9F3C9@BN0PR01MB6845.prod.exchangelabs.com>
In-Reply-To: <BN0PR01MB68453E68300E91AC94DE3E8B9F3C9@BN0PR01MB6845.prod.exchangelabs.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [142.136.235.122]
Content-Type: multipart/related; boundary="_004_3ad9cf3747ff4423875ecf1943b0961dncemexgp037CORPCHARTERC_"; type="multipart/alternative"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/softwires/Vo6k5wiQ3jHZn0pNlMlzdMO4zu4>
X-Mailman-Approved-At: Wed, 09 Nov 2022 05:01:18 -0800
Subject: Re: [Softwires] MAP-T issue - UDP packets with zero checksum
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: softwires wg discussion list <softwires.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/softwires>, <mailto:softwires-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/softwires/>
List-Post: <mailto:softwires@ietf.org>
List-Help: <mailto:softwires-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/softwires>, <mailto:softwires-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 07 Nov 2022 16:05:13 -0000

Michael,

That looks good to me.  I like the new language.

-Jordan

From: Overcash, Michael (CCI-Atlanta) <michael.overcash@cox.com>
Sent: Monday, November 7, 2022 8:12 AM
To: Gottlieb, Jordan J <Jordan.Gottlieb@charter.com>; Rajiv Asati (rajiva) <rajiva@cisco.com>; Poscic, Kristian (Nokia - US) <kristian.poscic@nokia.com>
Cc: softwires@ietf.org
Subject: [EXTERNAL] RE: [Softwires] MAP-T issue - UDP packets with zero checksum

CAUTION: The e-mail below is from an external source. Please exercise caution before opening attachments, clicking links, or following guidance.
OK so I took a fresh look at all this this morning. Took two cups of coffee.

RFC 7915 section 4.5 is definitely relevant. It says the IPv4-to-IPv6 translator SHOULD either drop the packet or recalculate the checksum. I agree this is a reasonable burden for the CE but too expensive for the BR.

Maybe we can proceed as follows:
1)      Add RFC 7915 as a normative reference.
2)      Clarify that as stated in RFC 7915, the CE SHOULD recalculate the checksum for upstream traffic.
3)      Discuss that recalculating the checksum is an unreasonable burden on the BR. The BR MAY recalculate the checksum. If the BR does not recalculate the checksum, it MUST provide a configuration to forward the IPv6 packet with a zero checksum to promote interoperability.

Does this seem reasonable?

Michael Overcash
Principal Architect, Premises Technology
C 678.637.5649

[cid:image002.png@01D8F288.06A1A300]

From: Gottlieb, Jordan J <Jordan.Gottlieb@charter.com<mailto:Jordan.Gottlieb@charter.com>>
Sent: Friday, November 4, 2022 5:29 PM
To: Overcash, Michael (CCI-Atlanta) <michael.overcash@cox.com<mailto:michael.overcash@cox.com>>; Rajiv Asati (rajiva) <rajiva@cisco.com<mailto:rajiva@cisco.com>>; Poscic, Kristian (Nokia - US) <kristian.poscic@nokia.com<mailto:kristian.poscic@nokia.com>>
Cc: softwires@ietf.org<mailto:softwires@ietf.org>
Subject: [EXTERNAL] Re: [Softwires] MAP-T issue - UDP packets with zero checksum


My concern making it a "MUST" in any case.



On the CE side you really do want to do UDP checksum on the MAP-T CE as a IPv4-mapped IPv6 address connection to an asset such as a edge cache would break with no checksum.  There is no way for us to know what the UEs will be doing with regard to IPv4 UDP checksum.



On the BR side I think it should just remain a "SHOULD".  Generally speaking the operator can decide what is best for their network based on their use cases.



Sincerely,



Jordan

________________________________
From: Overcash, Michael (CCI-Atlanta) <michael.overcash@cox.com<mailto:michael.overcash@cox.com>>
Sent: Friday, November 4, 2022 12:09 PM
To: Gottlieb, Jordan J; Rajiv Asati (rajiva); Poscic, Kristian (Nokia - US)
Cc: softwires@ietf.org<mailto:softwires@ietf.org>
Subject: [EXTERNAL] RE: [Softwires] MAP-T issue - UDP packets with zero checksum

CAUTION: The e-mail below is from an external source. Please exercise caution before opening attachments, clicking links, or following guidance.
@Ravij: correct, I am suggesting that the CE and BR MUST forward datagrams with zero checksum. The end-to-end goal is that if IPv4 zero-checksum datagrams go in one end, they pop out as zero-checksum datagrams on the other end.

@Jordan: I’m not sure I quite follow your concern… did I just address it?

Michael Overcash
Principal Architect, Premises Technology
C 678.637.5649

[cid:image002.png@01D8F288.06A1A300]

From: Gottlieb, Jordan J <Jordan.Gottlieb@charter.com<mailto:Jordan.Gottlieb@charter.com>>
Sent: Friday, November 4, 2022 1:30 PM
To: Rajiv Asati (rajiva) <rajiva@cisco.com<mailto:rajiva@cisco.com>>; Poscic, Kristian (Nokia - US) <kristian.poscic@nokia.com<mailto:kristian.poscic@nokia.com>>
Cc: Overcash, Michael (CCI-Atlanta) <michael.overcash@cox.com<mailto:michael.overcash@cox.com>>; softwires@ietf.org<mailto:softwires@ietf.org>
Subject: [EXTERNAL] RE: [Softwires] MAP-T issue - UDP packets with zero checksum

I think this is going to be very implementation specific and I am in the option that changing to a MUST is too constraining.  This is especially true when considering the CE case as stated at the start of the thread.  Think QUIC to IPv4-Mapped IPv6 addressed CDN.  Even in the BR case (though I do not apply it) I think it is not wise to employ this constraint as there are some possible use cases where this would be impactful.

-Jordan

From: Rajiv Asati (rajiva) <rajiva@cisco.com<mailto:rajiva@cisco.com>>
Sent: Friday, November 4, 2022 10:49 AM
To: Poscic, Kristian (Nokia - US) <kristian.poscic@nokia.com<mailto:kristian.poscic@nokia.com>>
Cc: Gottlieb, Jordan J <Jordan.Gottlieb@charter.com<mailto:Jordan.Gottlieb@charter.com>>; Overcash, Michael (CCI-Atlanta) <michael.overcash@cox.com<mailto:michael.overcash@cox.com>>; softwires@ietf.org<mailto:softwires@ietf.org>
Subject: [EXTERNAL] Re: [Softwires] MAP-T issue - UDP packets with zero checksum

CAUTION: The e-mail below is from an external source. Please exercise caution before opening attachments, clicking links, or following guidance.

Jordan’s distinction about tunneling vs translation is key here given the considerations for the normative language.

Mike’s suggestion is not that BR should calculate checksum, rather that BR should forward packets with UDP checksum being 0. Is that right, Mike? If so, then it is reasonable.

Cheers,
Rajiv Asati
VP.CTO, Cisco

“Focus on what we can do with what we have, not the other way around.”


On Nov 4, 2022, at 9:19 AM, Poscic, Kristian (Nokia - US) <kristian.poscic@nokia.com<mailto:kristian.poscic@nokia.com>> wrote:

I agree with Jordan, that it should NOT be made a MUST.
In the extreme, someone can use this as attack so that BR does nothing but recalculates checksums.
Kris

From: Softwires <softwires-bounces@ietf.org<mailto:softwires-bounces@ietf.org>> On Behalf Of Gottlieb, Jordan J
Sent: Friday, November 4, 2022 11:12 AM
To: Overcash, Michael (CCI-Atlanta) <michael.overcash@cox.com<mailto:michael.overcash@cox.com>>; softwires@ietf.org<mailto:softwires@ietf.org>
Subject: Re: [Softwires] MAP-T issue - UDP packets with zero checksum

Hi all,

I just to highlight that RFC6145 (a normative reference to RFC7599) which is obsoleted by RFC7915 covers this in detail.  They very appropriately have assigned a SHOULD on the calculation function of zero checksum IPv4 traffic.   I also want to point out that rfc6936 addresses tunneling protocol rather than a header translation based softwire and therefore should not be included as any kind of reference to RFC7599.

I am very much opposed to making it a MUST as it has significant performance implications on the BR.  It makes more sense on the CE for outgoing traffic as it has significant implications for IPv4-mapped IPv6 address traffic.

Sincerely,

Jordan

From: Softwires <softwires-bounces@ietf.org<mailto:softwires-bounces@ietf.org>> On Behalf Of Overcash, Michael (CCI-Atlanta)
Sent: Friday, November 4, 2022 7:44 AM
To: softwires@ietf.org<mailto:softwires@ietf.org>
Subject: [EXTERNAL] [Softwires] MAP-T issue - UDP packets with zero checksum

CAUTION: The e-mail below is from an external source. Please exercise caution before opening attachments, clicking links, or following guidance.
Hi,

IPv4 packets are allowed to have a zero checksum, but IPv6 packets are not. The problem of tunnelling zero checksum IPv4 packets through IPv6 tunnels is described in RFC 6935.

Currently RFC 7599 doesn’t address this issue, and as a result we’ve found that some existing BR and CE implementations don’t handle zero checksum UDP IPv4 packets correctly.

I think it would be helpful to add RFC 6935 as a normative reference and add a new section 8.5 to discuss the issue. Something like the following would help:
8.5. UDP Checksum Considerations
IPv4 UDP packets arriving at the BR or CE are can have a checksum value of zero, indicating no checksum was calculated. Historically, a zero checksum value is not
permitted in IPv6 UDP datagrams, and some implementations will discard these packets. The MAP-T CE and BR MUST translate and forward zero checksum UDP
datagrams in both the IPv4 and IPv6 domains as described in [RFC6935].

The text above could use some wordsmithing, but hopefully you get the idea.

Michael Overcash
Principal Architect, Premises Technology
C 678.637.5649

<image001.png>

_______________________________________________
Softwires mailing list
Softwires@ietf.org<mailto:Softwires@ietf.org>
https://www.ietf.org/mailman/listinfo/softwires<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/softwires__;!!Hit2Ag!wjS6zL7RadF7fHzUCc7H03UenqQsbxtrrJW3EHisODDmXva_L7ZNT4ZqehJVlqqKP_YJY06jSCVqEd_c7WdlXUw1jtsvO8E$>