From buraglio@forwardingplane.net Mon Feb 5 13:20:32 2024 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BFC4C14F6A5 for ; Mon, 5 Feb 2024 13:20:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.106 X-Spam-Level: X-Spam-Status: No, score=-2.106 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_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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 (1024-bit key) header.d=forwardingplane.net 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 fMuiMDJhiiiK for ; Mon, 5 Feb 2024 13:20:27 -0800 (PST) Received: from mail-qt1-x82c.google.com (mail-qt1-x82c.google.com [IPv6:2607:f8b0:4864:20::82c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA7EDC14F69E for ; Mon, 5 Feb 2024 13:20:27 -0800 (PST) Received: by mail-qt1-x82c.google.com with SMTP id d75a77b69052e-42bf29aff0dso34515671cf.3 for ; Mon, 05 Feb 2024 13:20:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forwardingplane.net; s=google; t=1707168026; x=1707772826; darn=ietf.org; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=c0xjir/f6da1DfTsx3oCN8au27Lelcwmc5skWBiQzgk=; b=sVAqUu38tDUv0KZn/W8jE9rTUTObUP9RaPpTiA5nIUx+lZ/uF7IXgmCf1nAhSDnmWI 81M4Vo3QKt1179zWBNILvRZoNCkPJxKfW/cnwkTc339AglJg1B4QCRCtH0Nubq98QZDt IFNcthTXJ4+ZnzBueoDCm5LtM5m1o+z8rUmnU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1707168026; x=1707772826; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=c0xjir/f6da1DfTsx3oCN8au27Lelcwmc5skWBiQzgk=; b=jhjhNR6rXZw0eNBXEAM8XVrTJwY0JW51yht6k4+8sSRY9JlngGIsXSKzacAjNketuF IKLNTK6mMcTjJ4jLVy1bcS/+prN0eKXEFlvJL+qvTntA7QTaHXGJT4eSeJUZ+CfCW1cK CB3bCO4eZIst16+K4HqybbLkD3nFIsU0vZamcYsP1caoRf5sJSOrbq4k7qbFVDV/PYCA piMhNVycRIHsBJi9H50ogI+tgs98og2WFdNBlo2i2urpiNOt/X3n9Vide59HSDsv1Lkg 5waQO6thhQ7uEcxZ/P6CZo4eyJ4E0yoOZoTtGLVDIBTIcRNie3vEC6wTaDz6lT6Pz2kN Yufw== X-Gm-Message-State: AOJu0YyugrR0dhYI4CdVSmRfZusoMnNcvggop7RIAgc0a4B2eQSIBesO dQZT42SjqNOOR1dJQKT3kaayyeBWd71Z+x8YDx5RO58Fhl8GAHQlvP5qR5ZDs8qxMl6xpdrDYF1 QM8Tj4Ty+3GJjWQSPrhx0WmL3mLDMW/Y5t2ZCjng+CshfiLCvOQ== X-Google-Smtp-Source: AGHT+IHVwNsGvq5oFjHZX+xEfmDfs/ZwCIQ1qWM8MmQma9LTKJ6jAQ6AIbawRnPJcAq0AnmXA+INeFR8nmwhsP80Ot4= X-Received: by 2002:a05:622a:28e:b0:42b:ff8d:3719 with SMTP id z14-20020a05622a028e00b0042bff8d3719mr696157qtw.67.1707168026614; Mon, 05 Feb 2024 13:20:26 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Nick Buraglio Date: Mon, 5 Feb 2024 15:20:15 -0600 Message-ID: To: "spring@ietf.org" Content-Type: multipart/alternative; boundary="000000000000cc71b70610a90706" Archived-At: Subject: Re: [spring] draft-ietf-spring-srv6-srh-compression X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.39 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Feb 2024 21:20:32 -0000 --000000000000cc71b70610a90706 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable There seems to be a fair amount of deployment and testing done here - Do we have broken behavior that is repeatable in the wild, or easily reproducible in a lab that can be shared? I understand the issue, I believe, but am looking for a repeatable broken example to fiddle with, and hoping someone has already done the legwork. I would love to read / see results and test case examples of things that should be considered. Existing work done in this space would be very useful for another document that is currently in the works. I see that Tom Herbert asked for something similar here https://mailarchive.ietf.org/arch/msg/spring/1Sq_KaDRUYD-HiG7iebbcodXNLA/ but I have not seen a reply. nb On Mon, Feb 5, 2024 at 1:32=E2=80=AFPM Andrew Alston - IETF wrote: > I call breaking any middleware that does checksum validation a problem - > and a big one > > > Andrew Alston > > Internal All Employees > ------------------------------ > *From:* Robert Raszuk > *Sent:* Monday, February 5, 2024 7:16:23 PM > *To:* Ron Bonica > *Cc:* Andrew Alston - IETF ; spring@ietf.org < > spring@ietf.org> > *Subject:* Re: [spring] draft-ietf-spring-srv6-srh-compression > > Hi Ron, > > Is there a problem ? > > If I read RFC8200 L4 checksum is computed by the packet *originator and > validated by the packet's ultimate receiver. * > > In all SPRING work to the best of my knowledge the vast majority of > packets are only encapsulated by transit nodes. > > Is there any formal mandate in any of the RFCs that an encapsulating node > must mangle the inner packet's L4 checksum ? I don't think so but stand > open to get my understanding corrected. > > Cheers, > Robert > > > > > > > On Mon, Feb 5, 2024 at 5:04=E2=80=AFPM Ron Bonica 40juniper.net@dmarc.ietf.org> wrote: > > Folks, > > Has anyone proposed a solution to the L4 checksum problem that Andrew > talks about? > > Ron > > Juniper Business Use Only > ------------------------------ > *From:* spring on behalf of Andrew Alston - > IETF > *Sent:* Monday, February 5, 2024 5:21 AM > *To:* spring@ietf.org > *Subject:* [spring] draft-ietf-spring-srv6-srh-compression > > > [External Email. Be cautious of content] > > Hi All, > > > > (In capacity as a contributor and wearing no other hats) > > > > At this point I cannot support progression of this document until the > issues around the L4 Checksum have been resolved. It=E2=80=99s been clea= rly stated > in other emails on the list that in certain circumstances the behavior > described in this document break the L4 checksum as defined in RFC8200. > This requires an update to RFC8200 to fix it =E2=80=93 and I=E2=80=99m no= t sure that spring > can update 8200 absent the consent of 6man, which I=E2=80=99m not sure ha= s been > asked for, nor am I sure that a spring document can update something like > 8200 in an area so fundamental as the checksum without a -BIS, which woul= d > have to be done via 6man. The L4 checksum issue though is real =E2=80=93= and it > cannot simply be ignored. > > > > I also have deep concerns that the compression document creates something > that (in a similar way to SRv6) creates something that is completely > non-conformant with RFC4291. There are multiple references to this in > draft-6man-sids, and should draft-6man-sids become an RFC I would argue > that it should probably be a normative reference in this document =E2=80= =93 on the > logic that this document relies on similar RFC4291 violations that srv6 > itself does (and for the record, just because SRv6 itself violates RFC429= 1 > as is clearly documented in draft-6man-sids =E2=80=93 does not make it ac= ceptable > to do so in yet another draft without clear and unambiguously stating the > deviations and ideally updating RFC4291 to allow for said deviations) > > > > I believe these two issues alone are sufficient that to pass this documen= t > would create still further tensions about the relationship between SRv6 a= nd > IPv6 and lead to confusion. As such =E2=80=93 I believe these issues nee= d to be > adequately dealt with =E2=80=93 and the solutions to them need to be appr= oved by > 6man as the working group that holds responsibility for ipv6 maintenance. > > > > Thanks > > > > Andrew Alston > > > > > > Internal All Employees > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > --000000000000cc71b70610a90706 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
There seems to be a fair amount of deployment and testing = done here - Do we have broken behavior that is repeatable in the wild,=C2= =A0or easily reproducible=C2=A0in a lab that can be shared? I understand th= e=C2=A0issue, I believe, but am=C2=A0looking=C2=A0for=C2=A0a repeatable bro= ken=C2=A0example to=C2=A0fiddle with, and hoping someone has already done t= he legwork.=C2=A0
I would love to read / see results and test case exam= ples of things that should be considered. Existing work done in this space = would be very useful for another=C2=A0document that is currently in the wor= ks. I see that Tom Herbert asked for something similar here=C2=A0https://mailarchive.ietf.org/arch/msg/spring/1Sq_KaDRUYD-HiG7iebbcodXNLA/<= /a> but I have not seen a reply.=C2=A0

nb

On = Mon, Feb 5, 2024 at 1:32=E2=80=AFPM Andrew Alston - IETF <andrew-ietf=3D= 40liquid.tech@dmarc.ietf.or= g> wrote:
I call breaking any middleware that does checksum validati= on a problem - and a big one


Andrew Alston

Internal All Employees

From:= Robert Raszuk <r= obert@raszuk.net>
Sent: Monday, February 5, 2024 7:16:23 PM
To: Ron Bonica <rbonica@juniper.net>
Cc: Andrew Alston - IETF <andrew-ietf@liquid.tech>; spring@ietf.org <spring@ietf.org>
Subject: Re: [spring] draft-ietf-spring-srv6-srh-compression
=C2=A0
Hi Ron,=C2=A0

Is there a problem ?=C2=A0

If I read RFC8200 L4 checksum is computed by the packet originator = and validated by the=C2=A0packet's ultimate receiver.=C2=A0

In all SPRING work to the best of my knowledge the vast majority of pa= ckets are only encapsulated=C2=A0by transit nodes.=C2=A0

Is there any formal mandate in any of the RFCs that an encapsulating n= ode must mangle the inner packet's L4 checksum=C2=A0? I don't think= so but stand open=C2=A0to get my understanding corrected.=C2=A0

Cheers,
Robert






On Mon, Feb 5, 2024 at 5:04=E2=80=AFPM Ron Bonica <rbon= ica=3D40j= uniper.net@dmarc.ietf.org> wrote:
Folks,

Has anyone proposed a solution to the L4 checksum problem that Andrew talks= about?

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 R= on

Juniper Business Use Only

From: spring <spring-bounces@ietf.org> on behalf of Andrew A= lston - IETF <andrew-ietf=3D40liquid.tech@dmarc.ietf.org>
Sent: Monday, February 5, 2024 5:21 AM
To: spring@ietf= .org <spring@ie= tf.org>
Subject: [spring] draft-ietf-spring-srv6-srh-compression
=C2=A0

[External Email. Be cautious of content]=

Hi All,

=C2=A0

(In capacity as a contributor and wearing no other = hats)

=C2=A0

At this point I cannot support progression of this = document until the issues around the L4 Checksum have been resolved.=C2=A0 = It=E2=80=99s been clearly stated in other emails on the list that in certai= n circumstances the behavior described in this document break the L4 checksum as defined in RFC8200.=C2=A0 This requires = an update to RFC8200 to fix it =E2=80=93 and I=E2=80=99m not sure that spri= ng can update 8200 absent the consent of 6man, which I=E2=80=99m not sure h= as been asked for, nor am I sure that a spring document can update something like 8200 in an area so fundamental as the checksum without a -B= IS, which would have to be done via 6man.=C2=A0 The L4 checksum issue thoug= h is real =E2=80=93 and it cannot simply be ignored.

=C2=A0

I also have deep concerns that the compression docu= ment creates something that (in a similar way to SRv6) creates something th= at is completely non-conformant with RFC4291.=C2=A0 There are multiple refe= rences to this in draft-6man-sids, and should draft-6man-sids become an RFC I would argue that it should probably= be a normative reference in this document =E2=80=93 on the logic that this= document relies on similar RFC4291 violations that srv6 itself does (and f= or the record, just because SRv6 itself violates RFC4291 as is clearly documented in draft-6man-sids =E2=80=93 doe= s not make it acceptable to do so in yet another draft without clear and un= ambiguously stating the deviations and ideally updating RFC4291 to allow fo= r said deviations)

=C2=A0

I believe these two issues alone are sufficient tha= t to pass this document would create still further tensions about the relat= ionship between SRv6 and IPv6 and lead to confusion.=C2=A0 As such =E2=80= =93 I believe these issues need to be adequately dealt with =E2=80=93 and the solutions to them need to be approved by 6man= as the working group that holds responsibility for ipv6 maintenance.

=C2=A0

Thanks

=C2=A0

Andrew Alston

=C2=A0

=C2=A0


Internal All Employees

_______________________________________________
spring mailing list
spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
_______________________________________________
spring mailing list
spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
--000000000000cc71b70610a90706--