Boundless sequential and non-sequential CVE ID Reservations about cve-services

[david-waltermire-nist]

Ok. That sounds fine to me.

[david-waltermire-nist]

We discussed the following in the SPWG close to a couple years back, roughly paraphrased:

In an ideal world, CVE IDs would be given out on a one-by-one basis and would be assigned at the point when the CVE record is to be populated.

This is not a common practice today for various reasons.

Some reasons mentioned in the SPWG and from this week's summit include:

1. A CVE ID is needed earlier in the coordination process.; thus earlier allocation.
2. Some CNAs like to have groups of (nearly) adjacent IDs appear in the same advisory
3. Some CNAs prefer CVE IDs that have fewer digits. They are easier for a human to remember. CNAs also like low numbered CVEs for this reason.
4. Some CNAs have expressed that CVE IDs that are widely non-adjacent in the same advisory can be confusing to readers; other have stated that this is not a problem.

The following is my personal opinion given the above.

• For lowest numbered IDs in the CVE-YYYY-NNNN format, where NNNN is the minimum 4 digits (0000-9999) or (0001-9999), we should allocate these IDs randomly as single IDs. This promotes the ideal allocation strategy.
• The IDs in the 10000+ space can be assigned using Matt's proposed algorithm, working off a sequential block of 500 in the first (N)000, where N starts at 10. The remaining (N)500-(N)999 IDs can be allocated randomly I guess.

This will keep block allocations in the CVE-YYYY-10000 to CVE-YYYY-99499 range, if < 45k IDs are handed out.

Alternately, the blocks could be used in groups of 1000 to keep it simple. In this case, if the 0000-9999 ids run out, the next available block of 1000 can be used for individual ID assignment.

I think the above is in the spirit of what the SPWG wants. [I can confirm if this is desired with the SPWG.]

Going back to the SPWG requirements, we have the following MVP requirements:

• There is a need to establish hard quotas for IDs on a per CNA basis. We need to work out maximum allocation thresholds for each CNA based on the current block assignments numbers. [Jonathan can provide this info.] This will prevent a single CNA from over reserving beyond their established needs.
• Populated CVE IDs must not count towards a CNA's hard quota.
• The maximum allocation hard quota limit must be changeable for a CNA. This will allow adjustments to be made if a CNAs needs change. This is equivalent to handing out a new, additional block today.
• We should also establish a cap for the number of IDs that can be requested in a single request. This should be something like: minimum_of(hard_quota, 1000). 1000 is in the service description from the CVE services CONOPS. This number could be lower, maybe 100 or 150? [I can confirm this with the SPWG.]

[mattrbianchi]

@david-waltermire-nist Thanks for the feedback.

As for the extension of the proposal, I can see incentivizing non-sequential IDs through reserving the whole 4 digit range for them. It would be one more step, but the original proposal can still then build on that as the pool of 4 digit numbers diminish.

For the suggestion of using groups of 1000 to keep it simple, I'm not sure I'm following. First the non-sequential IDs have a pool of almost 10k to select from (all 4 digit numbers), then they only have the next clean section of 1000 available after that? I find that a bit more messy to code as the service would have to keep up with how far sequential IDs have progressed and make sure the sequential IDs then skip over the arbitrary 1000 block range taken for non-sequential IDs. It's much cleaner at first glance to allow the sequential side to climb up a half of the range and let the non-sequential side (somewhat) ascend the other.

Finally, for the hard quota requirements, I know those are valid requirements for an MVP, but I'd rather them not be communicated in a comment thread discussing a separate proposal. All of them do make sense though!

As I'm reading them though, I'm worried I've made a mistake in vocabulary which made it feel necessary for you to mention them. When I used the word block, I simply meant there is a 500 number block of sequential IDs available per every thousand in the original proposal. I realize now blocks have been used to describe the number of IDs a CNA obtains in a single "request". I instead used the word batch to connotate that action. I did not mean to suggest clients would only take 500 sequential IDs at a time (that would indeed depend on their quota as you mention) but that when they requested a batch of say 5 sequential IDs, those IDs would originate from the next numbers available in the lowest block of 500 reserved for sequential IDs.

[david-waltermire-nist]

@mattrbianchi I added a new issue (#19) for the hard allocation limits.

I like the distinction between "batch" and "block". Can you update your proposal with this language?

I am not a fan of the "allow the sequential side to climb up a half of the range and let the non-sequential side (somewhat) ascend the other." What happens when the two meet? Since the range of numbers is effectively unbounded, it seems more scalable to just allocate the next block for individual assignments. Some state tracking is going to be needed to support the current batch assignment block. Why not do the same for the single allocation block that is initially 0001-9999?

While I can live with any bookkeeping solution, I think we need to be careful that we don't build fragile code that blows up on us in the future when we least expect it. We want a solid solution that we can build on and that CNAs can rely on. It would be good to find a workable solution that we don't need to revisit if possible.

[mattrbianchi]

@david-waltermire-nist I think I might need to provide more examples for the original solution to convey how it will work. You seem to think "the two will meet" when in fact in the original proposal ensures they never will. Sequential IDs are only taken from IDs ending in 1-500 and non-sequential IDs only taken from IDs ending in 501-000.

I find two columns become visualized in my mind when thinking about this strategy, where one column is sequential IDs and the other non-sequential and the two never "meet":

sequential	non-sequential
0001-0500	0501-1000
1001-1500	1501-2000
2001-2500	2501-3000
(∞)001-(∞)500	(∞)501-(∞+1)000

Hopefully the table helps your understanding, I'll look to add it to the proposal along with emphasis in the writing and definitions for the terms batch and block.

I, too, agree that we should avoid writing fragile code and should have a solid solution that doesn't require revisiting. That is why I find this provided solution from a community member such a good one. Sequential IDs have to only keep up with where the last sequential IDs were given and go from there within its rule of ending in 1-500. Meanwhile, the pool for non-sequential IDs is populated with IDs ending in 501-000. When the pool needs more numbers, the next numbers ending in 501-000 are added instead of having to check whether the sequential process has taken a whole thousands range. It avoids them ever stepping on each other which avoids a lot of state and what would essentially be similar to a shared memory problem (very nasty).

Any way we can avoid having to figure out if the non-sequential or the sequential range has "claimed" a block avoids complicated and fragile code that would have to be wrapped in mutexes/semaphores to ensure a block isn't accidentally "booked" for both sequential and non-sequential allocation.