Re: [Sidrops] I-D Action: draft-ietf-sidrops-rpki-rsc-07.txt

Job Snijders <job@fastly.com> Tue, 24 May 2022 09:49 UTC

Return-Path: <job@fastly.com>
X-Original-To: sidrops@ietfa.amsl.com
Delivered-To: sidrops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92B43C14F749 for <sidrops@ietfa.amsl.com>; Tue, 24 May 2022 02:49:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fastly.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 OUHNaTazIYvQ for <sidrops@ietfa.amsl.com>; Tue, 24 May 2022 02:49:37 -0700 (PDT)
Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com [IPv6:2a00:1450:4864:20::631]) (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 F023CC14F716 for <sidrops@ietf.org>; Tue, 24 May 2022 02:49:37 -0700 (PDT)
Received: by mail-ej1-x631.google.com with SMTP id q21so13989873ejm.1 for <sidrops@ietf.org>; Tue, 24 May 2022 02:49:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastly.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=RJAdimkcs4QrQz8Svn4OEvN8I04rFwfcivm0aVD10+E=; b=Q4SIFRWKSLyhydhzVUvsJ6r1ecZKnnG9DzwT0ahBIBpSvPE8X+22q4swNPE9XFJXZo c45CweT8wsqULV+TBlbxh4ztvGrRqa2WPO6VJ0218WpKdhteI7Qv7Lti5fJNm/NkmVnC WbJpOcziFYpcwyK98tZ8It/EL1SmUqI0TUfKo=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=RJAdimkcs4QrQz8Svn4OEvN8I04rFwfcivm0aVD10+E=; b=kR4Q3zBwarFb4jM5hVD/lzfpa64rtLgsv8yo41OWsOJhOl8iJwpPjm1SYflGOLvwak EAuUpvnuUZQ0lAsrKcNAPOJa8qF+4NpvMtRDPt0OM/+JAtAgz4nSYj3OtHaWzNQdmIIN jUYzXeIm7oFt8792LnwmtAycMhUBMVcCbipQQ2kzCFqUHBQDnYWRToKIdVuZNJo0Cgnu 01nP0FoNWPQhdh0JdwK2xlA/NM21s+KvZ2X2Bq4tbXDne8RmUT8LzxbH6cVwRT1M4lcO NfTpRFqhai9cmdMNEh/HcY+5s0BQbT1zAz6HWUlesU/1lzX7MHoTIbA8l38rvCyv/8Sz 9oIw==
X-Gm-Message-State: AOAM5302LcboCrBvZEwQPZ5XoH+/jKWXMhTtuKWqD2OjPWzOgkm2se0o t+TCHoVKPP4YrE77DozU+ryYoZmkaM9dDw==
X-Google-Smtp-Source: ABdhPJz5IRwJ1evkW9oQeeUfeud1bzfvB9KzvuKola8ANNhZ03bANHdCzvgKUaU9UdXW5uUBRfrKqg==
X-Received: by 2002:a17:906:2658:b0:6fe:deae:cf0d with SMTP id i24-20020a170906265800b006fedeaecf0dmr8742997ejc.119.1653385776081; Tue, 24 May 2022 02:49:36 -0700 (PDT)
Received: from snel ([2a10:3781:276:2:16f6:d8ff:fe47:2eb7]) by smtp.gmail.com with ESMTPSA id d11-20020aa7ce0b000000b00428bb4c952bsm9338759edv.31.2022.05.24.02.49.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 24 May 2022 02:49:35 -0700 (PDT)
Date: Tue, 24 May 2022 11:49:33 +0200
From: Job Snijders <job@fastly.com>
To: Russ Housley <housley@vigilsec.com>
Cc: Theo Buehler <tb@theobuehler.org>, Job Snijders <job=40fastly.com@dmarc.ietf.org>, George Michaelson <ggm@algebras.org>, Ben Maddison <benm@workonline.africa>, Randy Bush <randy@psg.com>, SIDR Operations WG <sidrops@ietf.org>
Message-ID: <YoyqLTIG/ZG2LMZa@snel>
References: <m2o7ztfe4d.wl-randy@psg.com> <20220520012253.zu4abj7kotvg3m3z@benm-laptop> <80AD7E72-1F42-4314-B0A8-69819904F2EB@vigilsec.com> <20220520135826.23h6eaurre7zvqxs@benm-laptop> <17C2DA7E-A5CB-49EE-8148-FB223A12D992@vigilsec.com> <CAKr6gn1vcma0=2v4k9i+i6C3Z4odx5A=vn+yFVQZJVkFicZwRA@mail.gmail.com> <YovdiIzWJ1Cw3QUO@snel> <F51216BA-1556-4441-8048-7B0258F0F959@vigilsec.com> <YoycSh4wUtbjP7E5@theobuehler.org> <F5B89898-C00D-4371-B2E4-B5AE9407B8D8@vigilsec.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <F5B89898-C00D-4371-B2E4-B5AE9407B8D8@vigilsec.com>
X-Clacks-Overhead: GNU Terry Pratchett
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/g5tXWMZgUD6R0c7ctXUqYjpodXA>
Subject: Re: [Sidrops] I-D Action: draft-ietf-sidrops-rpki-rsc-07.txt
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.34
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 24 May 2022 09:49:41 -0000

On Tue, May 24, 2022 at 05:28:38AM -0400, Russ Housley wrote:
> > What puzzles me about this position is that one can construct exactly
> > the same argument about 'inherit' or 'rdi'.
> > 
> > What is the distinction that makes a decode failure acceptable if an
> > existing RFC 3779 implementation generates 'inherit' or 'rdi' but
> > not if it generates a 3-octet value in an addressFamily? Is it
> > because the latter mistake is somehow smaller and easier to make?
> 
> I do not see these as similar situations. RFC 3779 is intended for use
> in a RPKI certificate, where the is a issuer certificate that one
> could expect to be readily available for path validation.
> 
> Also, RFC 3779 defines:
> 
>    IPAddressFamily     ::= SEQUENCE {    -- AFI & optional SAFI --
>       addressFamily        OCTET STRING (SIZE (2..3)),
>       ipAddressChoice      IPAddressChoice }
> 
>    IPAddressChoice     ::= CHOICE {
>       inherit              NULL, -- inherit from issuer --
>       addressesOrRanges    SEQUENCE OF IPAddressOrRange }
>
> This draft proposes:
> 
>   ConstrainedIPAddressFamily   ::= SEQUENCE { -- AFI & opt SAFI --
>    addressFamily        OCTET STRING (SIZE (2)),
>    ipAddressChoice      SEQUENCE (SIZE(1..MAX)) OF IPAddressOrRange }
>
> When the addressesOrRanges CHOICE is selected, the two would produce
> the same bits on the wire, except the third octet is not permitted.

Right, the third octet is not permitted, which is why the RSC ASN.1
module does not offer space for the third octet to exist.

If the RSC ASN.1 notation does not offer room for the SAFI octet to
exist; my expectation is that this in and of itself is an unambigious
signal to signer/validator implenmenters to not include the SAFI.

What advantage is there to permitting the third octet to exist on the
wire (according to RSC ASN.1 module), but subsequently implore upon
signer and validator implementers to reject RSC objects when the third
octet is encountered?

Kind regards,

Job