[spring] Re: [IPv6]Re: C-SIDs and Upper-Layer Checksums (draft-ietf-spring-srv6-srh-compression)

Gyan Mishra <hayabusagsm@gmail.com> Fri, 14 June 2024 05:30 UTC

Return-Path: <hayabusagsm@gmail.com>
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 2D055C180B48; Thu, 13 Jun 2024 22:30:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.108
X-Spam-Level:
X-Spam-Status: No, score=-2.108 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 mm9wn43eafaS; Thu, 13 Jun 2024 22:30:06 -0700 (PDT)
Received: from mail-pj1-x1032.google.com (mail-pj1-x1032.google.com [IPv6:2607:f8b0:4864:20::1032]) (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 275EEC14F6BF; Thu, 13 Jun 2024 22:30:06 -0700 (PDT)
Received: by mail-pj1-x1032.google.com with SMTP id 98e67ed59e1d1-2c2c6b27428so1425501a91.3; Thu, 13 Jun 2024 22:30:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1718343005; x=1718947805; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=57MhC7NGOYTG5lUF6Acx/bC/JEdkOFx34FlXqFaNqLc=; b=P+PFQuUnLtxuvPRT400sX5Yh+pF07xJ16Q8vfgckmBV6NpvhYkb/lb5jyEIwmNjNzP KVxjkLJe/JWtfniS4xsDKpxfaLsZWpyVbDhxaMR0FfEFXM5orW1WNoVUiQDiHUXGuqTD o6xeI44Pt+Thfu2ZbD0tj+5zFuzA0ZHM2VhwQb1Gpe1Jbn34WE+BzkXUaCsnA32jhNAh ZoyyBJ2utgASwtOGyMN8tlNMzKsTgUz+3OYkm2Rd8UyWPE8GlY2cjMCZJI2JVBhLD2FH FTg0qqpXq2rDVP3/5nIPzdJ6ZhA5TrdsLrmeaAVPKV8NaVi5UfoBpvnequZFJB9Cmd3l dKOg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1718343005; x=1718947805; h=cc: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=57MhC7NGOYTG5lUF6Acx/bC/JEdkOFx34FlXqFaNqLc=; b=HTc2LwHYOPPC9MCCXAYJBiD9I2wtQjjcVaBhb44GeX6wVydGsJK7Yy4okF8ZldJgom ZqTfzXC0Y5QUA5CrfU1R11pT1xcNLOS9WKD2kezNQy3QPXXjFs7a4rl9IddzmhXGaixt VhSWk2VaiQwaCEdI+OrY1okxiGBy8/Db2NFiKzIX/9DGKra6U0U25FlO2F/HdhNNFX7L 6AyBCg7FN+zE+sw/zSaSv0+LDJmiK7+iMew6PicfZNc3kIBcYldizblTyTQJRJHJ2nLw fFRoz00PWlYGc2P9egbB+QK+8Y7SAcK/0kmKGiRxC51UinfEbLk3hzE90cwhrAXiCybG uhfw==
X-Forwarded-Encrypted: i=1; AJvYcCXnMkgNgbTbscE+38I84npYo9gusgTykdRw27MDBssrWCqWUiZVilwmaOeCY5E1vTg5NES8AiIdz61ZShD160/J6SwIJyUFynDoqNHFKtW1045BQySuBt6wZeGWCPNLfFCylAQ1RPognw/B7SYO/we6OcuZVFRT5fKqKCEeCzJjALqKYlU7SdeGTKW7jrAfdQ7P
X-Gm-Message-State: AOJu0YwJ+ahVmlftFFIuGG3QJMUOeRjA5cx1qVkCl3wBuO0f8pISFxdK uzCO87UUIyG5JDlVSdT+mFcMkYJsSURRWq+leTm6T/lOKHvodb8Ub/NOg9/mTofOWN2SpnFsPku 3XYAfbpt9VEpD+iSGo1gqJCNWZHk=
X-Google-Smtp-Source: AGHT+IGrk8WXgKhhovfCU4zyintcY5gklvypLe/9hUETHx3XkTHqq2AEOHNlFr/HpTy946zJiMcj4D6Cf4Qukn97AHI=
X-Received: by 2002:a17:90b:3786:b0:2c2:d0cc:3b9e with SMTP id 98e67ed59e1d1-2c4dbd37bd0mr1515360a91.46.1718343004892; Thu, 13 Jun 2024 22:30:04 -0700 (PDT)
MIME-Version: 1.0
References: <CAMMESsyrbnWJTCKxwbQusWWe0SRoRHqP7j069KYNRvsVPL6Zzg@mail.gmail.com> <DU2PR03MB8021FFDA47C7B5A659E39ABEFAC12@DU2PR03MB8021.eurprd03.prod.outlook.com> <CALx6S35s08-L-CnPxY8LSLaRib+=g8X8=vJaKDEDXC+TMFJwzA@mail.gmail.com> <CAOj+MMFbgUeEvqEjYKu=kJcXcc+-O09JXHCA2ozz7R+BOd7Rqw@mail.gmail.com> <CALx6S342t1XKvCTX0Zgj5Quew7MVtOH0wNoew_mYb0QUTZ3JOQ@mail.gmail.com> <CAOj+MMGkRXZe9uVXabOtrz2tuXreWonbSdPne1Jwq81JUKXNEg@mail.gmail.com> <CALx6S35fQKHKGRbB_myYJCjv3Pc_yjYh4axQLtSRzvE6me+oBA@mail.gmail.com>
In-Reply-To: <CALx6S35fQKHKGRbB_myYJCjv3Pc_yjYh4axQLtSRzvE6me+oBA@mail.gmail.com>
From: Gyan Mishra <hayabusagsm@gmail.com>
Date: Fri, 14 Jun 2024 01:29:53 -0400
Message-ID: <CABNhwV1WrYiJ4rBwVG_A3BO+zKbC3BgeuJYPNNJi5JgX0a0kYA@mail.gmail.com>
To: Tom Herbert <tom=40herbertland.com@dmarc.ietf.org>
Content-Type: multipart/alternative; boundary="00000000000068b309061ad2e8df"
Message-ID-Hash: DPUBNVGA7MWDNQKKXJNGXMKCS6FB2TRM
X-Message-ID-Hash: DPUBNVGA7MWDNQKKXJNGXMKCS6FB2TRM
X-MailFrom: hayabusagsm@gmail.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-spring.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: 6man <ipv6@ietf.org>, 6man Chairs <6man-chairs@ietf.org>, Robert Raszuk <robert@raszuk.net>, SPRING WG List <spring@ietf.org>, "int-ads@ietf.org" <int-ads@ietf.org>, "rtg-ads@ietf.org" <rtg-ads@ietf.org>, "spring-chairs@ietf.org" <spring-chairs@ietf.org>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [spring] Re: [IPv6]Re: C-SIDs and Upper-Layer Checksums (draft-ietf-spring-srv6-srh-compression)
List-Id: "Source Packet Routing in NetworkinG (SPRING)" <spring.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/JIa0d-p142iwCN0aXz2X1d2M1F8>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spring>
List-Help: <mailto:spring-request@ietf.org?subject=help>
List-Owner: <mailto:spring-owner@ietf.org>
List-Post: <mailto:spring@ietf.org>
List-Subscribe: <mailto:spring-join@ietf.org>
List-Unsubscribe: <mailto:spring-leave@ietf.org>

Hi Tom / All

AFAIK what Robert is trying to say is that compare to IPv4, the IPv6 header
does not have a checksum field. The designers of IPv6 believed that the
link layer checksumming provided by protocols like PPP and Ethernet,
combined with checksums in upper layer protocols like TCP and UDP, would be
enough. They also wanted to make the header more efficient and easier to
process by removing the CRC check

So that being said the L4 upper layer protocols TCP, UDP would perform the
checksum which would be done by the session endpoints as Robert pointed
out.

Another point is that all customer traffic TCP, UDP endpoint flows would be
IPv6 encapsulated in the payload which would be unfettered and untouched
and thus the session endpoint would be perform the L4 checksum  would
succeed.

SRv6 would be deployed in a single administrative domain which could be
many domains or sub domains within a single administrative control.  In
that case the operator would take precaution's per the draft  as to middle
boxes being deployed in an SRv6 domain to avoid any L4 checksum issues or
upgrade as necessary to avoid any issues.  The rarity of this issue is that
not only would the operator have to deploy these middle boxes, but the
middle boxes as well would have to be session endpoints in the middle of
the SRv6 domain.  Quite rare.   I don’t see a  use case where a network
appliance middle box would be a session endpoint. Even a sniffer middle box
 would  be just mirroring the flows but would not be terminating the
session.  The only possible case I see is if a server was a middle box
siting as one of the transit nodes as a session endpoint.  In most operator
networks the underlay transport network P nodes are kept ultra clean and
stable minimal changes as well kept clean of any devices that could
comprise the integrity of the underlay.  That being said makes it even more
rare that an operator would put server or devices that could potentially be
harmful and impact stability of the SRv6 core transport.

I don’t see why there would be a need to update RFC 8200 to account for the
highly remote possibility of middle boxes L4 checksum issue given that it
is within an operators domain whom has full control to easily avoid this
circumstance or situation ever occurring at all costs.

Kind Regards

Gyan
On Thu, Jun 13, 2024 at 1:29 PM Tom Herbert <tom=
40herbertland.com@dmarc.ietf.org> wrote:

> On Thu, Jun 13, 2024 at 10:14 AM Robert Raszuk <robert@raszuk.net> wrote:
> >
> > Tom,
> >
> > For starter let's take a look at RFC1958 ..
> >
> > Entire document is pretty good including statements like this:
> >
> > The basic argument is that, as a first principle, certain required
> end-to-end functions can only be performed correctly by the end-systems
> themselves.
>
> Robert,
>
> RFC1958 does not mention the checksum nor any normative protocol
> requirements. And if we're going to base the argument on principles,
> then I'll quote the robustness principle: "Be conservative in what you
> send". For the past thirty years the checksum has always been sent to
> be correct on the wire unless there's a routing header, so changing
> that behavior would be a violation of the robustness principle.
>
> Tom
>
>
> Tom
>
> >
> > Thx,
> > R.
> >
> >
> > On Thu, Jun 13, 2024 at 6:54 PM Tom Herbert <tom@herbertland.com> wrote:
> >>
> >> On Thu, Jun 13, 2024 at 9:28 AM Robert Raszuk <robert@raszuk.net>
> wrote:
> >> >
> >> > All,
> >> >
> >> > As far as I recall during IPv6 discussions a notion of end-to-end
> principle of Internet design was treated as paramount. Number of decisions
> made in shaping IPv6 encoding were derived from this.
> >> >
> >> > One of those is checksum which has been removed from the IP header
> and shifted to higher layers (TCP or UDP or UDP-light etc ...).
> >> >
> >> > That means that no transit node (ie the node which is not the
> ultimate destination of the transport and above layers) have the right to
> validate any IPv6 checksum. If it is being done that is a spec violation
> and they should do it at their own risk.
> >>
> >> Robert,
> >>
> >> Please cite the RFC that expressly forbids an intermediate node from
> >> validating the transport layer checksum for operational or debugging
> >> purposes
> >>
> >> Tom
> >>
> >> >
> >> > So with that "the time has come to say" that this discussion which
> aims to simply block the subject draft which many customers do use today
> for various real network applications should just end.
> >> >
> >> > Regards,
> >> > Robert
> >> >
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests:
> --------------------------------------------------------------------
>