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

[George Michaelson <[e-mail]>]

My personal view is that the most likely path to code,  is code reuse and
changing encoding of these elements for one element like this is a tiny
saving in ASN.1 outcome for a higher degree of uncertainty in compatibility
should anyone fail to notice the difference.

It's a long time since I coded to asn.1 in anger but I still think POLA and
caution says "don't do this change" Keep it aligned.

I think I'm agreeing with Russ and Randy basically.


On Sat, 21 May 2022, 3:52 am Russ Housley, <[e-mail]> wrote:

> 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
>
> _______________________________________________
> Sidrops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sidrops
>