[OPSAWG]Re: I-D Action: draft-ietf-opsawg-prefix-lengths-12.txt

[Oliver Gasser <[e-mail]>]

Hi Mahesh,

Responses to the COMMENTs are inline.

Cheers,

Oliver

On 12/5/25 7:20 PM, Mahesh Jethanandani wrote:
> Thanks to the authors for making the changes “live”.
> 
> In reviewing the changes, and the COMMENTS received, here are a few that 
> I have not seen addressed.
> 
> Eric Vyncke’s:
> 
> I do not see the rephrasing to include IPv4. Was that intentional?
> 
>     /> Section 1:/
>     /
>     /
>     /> Is it really only an IPv6 issue in `prefix size for IPv6
>     geolocation` ?/
>     /
>     /
>     /We'll rephrase this to include IPv4 as well./

We already rephrased this stating that this is a general problem, but 
especially problematic for IPv6 (due to its large address space).

> 
> /
> /
> I am not seeing the general statement here.
> 
>     /> /
>     /> ### Section 3.2/
>     /> /
>     /> Except for the first sentence, all the rest of this section
>     appears to work/
>     /> only with CGN and not proxies. Please clarify that this is also
>     applicable to/
>     /> proxies./
>     /
>     /
>     /We'll add a general statement that all statements about CGN in this /
>     /document also apply to proxies./

See Section 3: "In all places Carrier-Grade NAT or CGN is used in this 
document, this applies to proxies as well."

> 
> Did Russ confirm these observations?
> 
>     /> /
>     /> Why restricting to only unsigned files `When reading data from an
>     unsigned/
>     /> prefixlen file, one MUST ignore data outside the referring
>     inetnum: object's/
>     /> address range.` ? I do not see why signed files can escape this
>     common sense/
>     /> check./
>     /
>     /
>     /This is implicitly done as the signature won'T be valid for address /
>     /ranges outside the address range./
>     /
>     /
>     /@Russ can you confirm this?/

We'll make this explicit in the next revision to be submitted shortly.

>     /
>     /
>     /> /
>     /> ### Section 6/
>     /> /
>     /> Why using an IP address range rather than the usual prefix
>     notation used/
>     /> through all this I-D in `The RPKI Signature's IP address range
>     MUST match that/
>     /> of the prefixlen URL in the inetnum: that points to the prefixlen
>     file.` ?/
>     /
>     /
>     /@Russ I defer to you on this one./
> 
> 
> Erik Kline posted this comment, but did not send it out, but I think it 
> is not a bad idea.
> 
>     /### S3/
>     /
>     /
>     /* Consider possibly referencing RFC 4180 for CSV./
> 

We'll add that.

> 
> Deb had the following COMMENTs but I have not see a response. Gorry and 
> Roman had a similar comment.
> 
>     /Section 6:  So what is the chance that this is ever used?  And if
>     used, what is the chance that it will be done properly?  [according
>     to Section 9, para 4, 'not happening anytime soon'.]/
>     /
>     /
>     /Section 9: So the choices are implement this with weak or no
>     authentication, or with complex, stronger authentication (where the
>     struggle will be doing it securely/properly)?/

See here:
https://mailarchive.ietf.org/arch/msg/opsawg/nsq-Ex2HJL3DoW3l3TGo1Dp-mc4/

> 
> 
> Mike Bishop had a few COMMENTs as well
> 
> I am not sure if I am seeing the clarification.
> 
>     /> ### Empty fields/
>     /> /
>     /> Section 3 says "The first field MUST NOT be empty on lines which
>     are not/
>     /> comments, while the second and third field can be empty in
>     certain scenarios."/
>     /> However, the only instance where the second or third field can be
>     empty is/
>     /> mentioned in Section 3.3, where both are empty./
>     /> /
>     /> Please consider clarifying the first statement to indicate that
>     one empty field/
>     /> is valid only when both are empty, and replace/augment the "in
>     certain/
>     /> scenarios" with a forward-reference to this one scenario./
>     /> /
>     /> (Or if there are other scenarios, describe them.)/
>     /
>     /
>     /The third field can also be empty in the scenario where there is
>     exactly /
>     /'1' end-site in a prefix. We will clarify that./

The scenario is now explicitly mentioned in Section 3.1: "Note the third 
field being set to '1', which signals the absence of CGN or proxies. 
This has the same meaning as the third field being left empty in this 
scenario."

> 
> 
> and finally a couple of COMMENTs from Roman, for which I am not sure I 
> see a response (on list).
> 
>     /> /
>     /> ** Section 6/
>     />     Unfortunately, the RPSL in/
>     />     some repositories is weakly authenticated at best./
>     /> /
>     /> What does “weakly authenticated” mean?/
>     /> /
>     /> ** Section 9/
>     />     If signatures were mandatory, the above attack would be
>     stymied, but/
>     />     of course that is not happening anytime soon./
>     /> /
>     /> Perhaps explain the “… of course that is not happening anytime
>     soon” by articulating “why not”./
>     /> /
>     /
>     /
>     /I'll defer to @Russ Housley for the two points raised above./
> 

@Russ: Can you respond to the above two comments from Roman?

> 
> Will be happy to send the document for publication once these have been 
> addressed.
> 
> Thanks
> 
>> On Dec 4, 2025, at 7:28 AM, [e-mail] wrote:
>>
>> Internet-Draft draft-ietf-opsawg-prefix-lengths-12.txt is now 
>> available. It is
>> a work item of the Operations and Management Area Working Group 
>> (OPSAWG) WG of
>> the IETF.
>>
>>   Title:   Publishing End-Site Prefix Lengths
>>   Authors: Oliver Gasser
>>            Randy Bush
>>            Massimo Candela
>>            Russ Housley
>>   Name:    draft-ietf-opsawg-prefix-lengths-12.txt
>>   Pages:   31
>>   Dates:   2025-12-04
>>
>> Abstract:
>>
>>   This document specifies how to augment the Routing Policy
>>   Specification Language (RPSL) inetnum: class to refer specifically to
>>   prefixlen files which are comma-separated values (CSV) files used to
>>   specify end-site prefix lengths.  This document also describes an
>>   optional mechanism that uses the Resource Public Key Infrastructure
>>   (RPKI) to authenticate the prefixlen files.
>>
>> The IETF datatracker status page for this Internet-Draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-opsawg-prefix-lengths/
>>
>> There is also an HTMLized version available at:
>> https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-prefix-lengths-12
>>
>> A diff from the previous version is available at:
>> https://author-tools.ietf.org/iddiff?url2=draft-ietf-opsawg-prefix- 
>> lengths-12
>>
>> Internet-Drafts are also available by rsync at:
>> rsync.ietf.org::internet-drafts
>>
>>
> 
> 
> Mahesh Jethanandani
> [e-mail]
> 
> 
> 
> 
> 
>