[tcpm] 793bis: what to say about source routing

Wesley Eddy <wes@mti-systems.com> Tue, 30 November 2021 03:12 UTC

Return-Path: <wes@mti-systems.com>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D68CD3A0C9F for <tcpm@ietfa.amsl.com>; Mon, 29 Nov 2021 19:12:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mti-systems-com.20210112.gappssmtp.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 CdZwj6qdDOOc for <tcpm@ietfa.amsl.com>; Mon, 29 Nov 2021 19:12:09 -0800 (PST)
Received: from mail-qt1-x831.google.com (mail-qt1-x831.google.com [IPv6:2607:f8b0:4864:20::831]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7BA83A0C41 for <tcpm@ietf.org>; Mon, 29 Nov 2021 19:12:08 -0800 (PST)
Received: by mail-qt1-x831.google.com with SMTP id p19so18769167qtw.12 for <tcpm@ietf.org>; Mon, 29 Nov 2021 19:12:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mti-systems-com.20210112.gappssmtp.com; s=20210112; h=message-id:date:mime-version:user-agent:content-language:to:from :subject; bh=+qknum8k2k1+F/TsChIuT6uBnPv9rKpEAKNJCPBSAYM=; b=jLsRduyggUkVNZGb1SrMRZ6D4iPvcTYr14TRToGhlc7F+qvLPH4HNTne3Y8IxOwdSH Ubh/N75TfJ8fY95n1H68rg7jNPucds9jPO08RkBGZ3Iv7nSOkTQyjAVfPU0yTwbHCP79 RVNMEEZhOnaHhWby6PohMaqpQdtpmzxnxQYz0EMRpP7Mt0M40Ts5zi9zP5Sr0Q2tF1yR ZkJZGjq7YaE5Zqkmra7OLP/PzEi1tKEzf44Id5KD8azwDR8IhZWpnHxblUMcKjgvlDLb RlGJITLFbf88W3+dvOQGqRpt3cKq9lpZop0U8UzcjNyRUrMaQ3RezTcNHeLkdsrc5qAV 880A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent :content-language:to:from:subject; bh=+qknum8k2k1+F/TsChIuT6uBnPv9rKpEAKNJCPBSAYM=; b=qk64OH1T4u1hpAw//rVKMrCYf0ylr8PF5AdMWchqcDHAjnuEzzDS+Uqszz4uOfDd1/ klSeJLz311YxJYteyyoXzsd1GMhns7P7T8h5qMFNjjeapvC6MCef1qpphZ+gg7fnf7Ei i5LKHIYvZRgyZsl5RogS9hWf7qz3uViCFuviIbf1egYUV/GmdhKmxGu5fahxv4Xlnjkq pnN+0E2NvMcKrhJOBct1v3RRtBSOQYxjX28+kH1ag03VbnYGtjzTHNfiFTV77dn9QRRp 1/HKBgsnU94zMxP78Mxyw2k+RE3hlOLDswaqP2AaI+Nz5hpTC0d4hoRvWp/wMKwyU3pU Ed2Q==
X-Gm-Message-State: AOAM531pX7b1OefoC6QbzdkPuzvCLWFv9i7uLwngbdDoCe9BbI9ffAnV i6K/ums47+lLe76uoLJo+NmYwxDbRivWdQ==
X-Google-Smtp-Source: ABdhPJx6ykbHI0jcW6rBC0kvhwQaV7tPmlk0ARv/jCaOsnu+d7Zpzdx1F73H9HNOn//nkVNYYALPfA==
X-Received: by 2002:ac8:5f89:: with SMTP id j9mr48655375qta.391.1638241926560; Mon, 29 Nov 2021 19:12:06 -0800 (PST)
Received: from [192.168.1.17] (cpe-66-61-72-87.neo.res.rr.com. [66.61.72.87]) by smtp.gmail.com with ESMTPSA id o1sm10224042qtw.1.2021.11.29.19.12.05 for <tcpm@ietf.org> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 29 Nov 2021 19:12:06 -0800 (PST)
Content-Type: multipart/alternative; boundary="------------pxCArkgcW0ezUG5pZ0SKPRYw"
Message-ID: <242bd633-0a7b-51dd-9200-3e3360d75e83@mti-systems.com>
Date: Mon, 29 Nov 2021 22:12:04 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.3.2
Content-Language: en-US
To: tcpm IETF list <tcpm@ietf.org>
From: Wesley Eddy <wes@mti-systems.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/_su6VQn16Af6iT42dN7JBjbaQw4>
Subject: [tcpm] 793bis: what to say about source routing
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 30 Nov 2021 03:12:12 -0000

One of the IESG comments that needs to be addressed on 793bis regards 
source routing.  There is the comment:

    [S3.9.2.1]

    * I feel like there should be some additional caveat about security
       implications of support for source routing.  RFC 6274, for example, says
       packets with LSRR (6274s3.13.2.3) and SSRR (6274s3.13.2.4) options should
       be dropped, citing various security concerns.

       I'm not sure there needs to be a lot of text; perhaps just an observation
       that some end systems may not support the source route semantics described
       here for security (or policy) reasons?

After looking at what 6274 says (which is Informational) and 793bis, 
here are my main thoughts:

    (1) The text in question was written for IPv4, prior to IPv6 with
    its own methods (deprecated RH0, and now other things like segment
    routing).

    (2) I'm not aware of anything changing with regard to 1122's
    description of IPv4 source routing support in IP stacks.

    (3) Looking at defaults on popular Linux systems, it looks like
    "net.ipv4.conf.default.accept_source_route = 1" is not uncommon ...
    so source routing support probably still exists.  I didn't look at
    what the TCP code does though, with regard to incoming source routed
    packets to see if it matches what 793bis says.

So, my suggestion is that we rename that section of 793bis (section 
3.9.2.1) to be specific to *IPv4* source routing, and then append at the 
end of the section a sentence like:

    RFC 6274 describes security concerns with IP source routing, and
    source routing may be disabled or unsupported on some systems.

Does this sound good?  Note that it basically leaves any flavors of IPv6 
source routing unmentioned (which seems right, since there isn't 
anything on standards track to use).  I would be very happy if someone 
more knowledgeable about the state of source routing support and usage 
could check this and share their thoughts.