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

[Russ Housley <[e-mail]>]

Ben:

>>>>> Sorry that I was not clear.  Since the goal is to align with RFC 3779,
>>>>> we should use the same definition as was used there, which is OCTET
>>>>> STRING (SIZE (2..3)).
>>>> 
>>>> this makes more sense to me, as i do not see a win in having rules that
>>>> apply on wednesdays and fridays and not on other days of the week.  one
>>>> wants to be able to write tools that are not complicated unnecesarily.
>>>> 
>>> I think I am explaining the intent poorly. I will try again.
>>> 
>>> The intent is not to align with the ASN.1 definitions of 3779, but with
>>> the DER wire-format produced by implementations of 3779.
>>> 
> [..]
>>> 
>>> In the specific case of the addressFamily field, allowing the SAFI-byte
>>> in the ASN.1, but then requiring that it MUST be absent in normative
>>> text (as is the case in other RPKI RFCs, e.g. 6487) would run contrary
>>> to the above goals.
>>> Implementors would be forced to do the constraint check by hand, even if
>>> they were generating the other constraints from the ASN.1 definitions.
>>> 
>>> Hope that makes more sense?
>> 
>> Not for me.  As you explain, you want compatibility with the library.
>> It produces a 2 octet value.  That is compatible with OCTET STRING
>> (SIZE (2..3)).
>> 
> Yes, agreed. It is also compatible with OCTET STRING (SIZE (2)).
> 
>> I do not want someone to encode a value with the ASN.1 in RFC 3779 and
>> then have a decode failure by an implementation that uses this ASN.1.
>> 
> Not all possible values of 3779 types are permitted in the eContent of
> an RSC.
> 
> If someone encodes a value using an 3779 implementation that, for
> example, contains 'inherit' or a 3-octet addressFamily, puts that value
> in the eContent of an RSC, and then tries to decode the object, then a
> decode error *is* the proper outcome.

This is the RFC 3779 syntax:

   IPAddrBlocks        ::= SEQUENCE OF IPAddressFamily

   IPAddressFamily     ::= SEQUENCE {    -- AFI & optional SAFI --
      addressFamily        OCTET STRING (SIZE (2..3)),
      ipAddressChoice      IPAddressChoice }

   IPAddressChoice     ::= CHOICE {
      inherit              NULL, -- inherit from issuer --
      addressesOrRanges    SEQUENCE OF IPAddressOrRange }

   IPAddressOrRange    ::= CHOICE {
      addressPrefix        IPAddress,
      addressRange         IPAddressRange }

   IPAddressRange      ::= SEQUENCE {
      min                  IPAddress,
      max                  IPAddress }

   IPAddress           ::= BIT STRING

The inherit part has nothing to do with the size of the OCTET STRING.

The OCTET STRING (SIZE (2..3)) is explained with this code:

   The addressFamily element is an OCTET STRING containing a two-octet
   Address Family Identifier (AFI), in network byte order, optionally
   followed by a one-octet Subsequent Address Family Identifier (SAFI).
   AFIs and SAFIs are specified in [IANA-AFI] and [IANA-SAFI],
   respectively.

I understand that you are saying that the third octet will never be present in this context.

The difference in our position is whether a decode failure should happen if someone put it there.  In my view, a decode error creates an additional barriers to debugging.

Russ