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

[Russ Housley <[e-mail]>]

> On May 24, 2022, at 5:49 AM, Job Snijders <job=[e-mail]> wrote:
> 
> 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?

If some implementation copies the encodes RFC 3779 bytes that include the 3rd octet, when should the mistake be caught on the receiving side?  Decode failure is what will happen now.  I think checking after decode will be easier to debug and correct.

Russ