Support bare IP in ip_range fields

[ZLightning]

Describe the feature:

The ip_range should have a default mask to accept bare IP addresses that are appropriate for the type (/32 for IPv4 and /128 for IPv6) rather than rejecting the input. Using the example of an ip whitelist (as shown in the docs)

{
  "ip_whitelist" : "192.168.0.1"
}

should be equally as valid as

{
  "ip_whitelist" : "192.168.0.1/32"
}

They both represent a range starting and ending on a single IPv4 address, and it makes sense to support both formats since a large portion of whitelists/blocklists support both IP and CIDR notation in one file. Presently, an exception is thrown for the bare IP "Expected [ip/prefix] but was [192.168.0.1]".

[elasticmachine]

Pinging @elastic/es-search

[elasticmachine]

Pinging @elastic/es-core-features

[jakelandis]

Related: #38064

[pcsanwald]

We discussed this briefly on our FixIt call, and we don't see any downsides to making this change, assuming the IP spec allows single values for ranges (i.e. the / is not required).

CC @jtibshirani for visibility and also @not-napoleon who has been working in this space lately (aggs for range fields)

[rjernst]

I don't think the spec allows for the suffix to be optional. As noted in the original description, many whitelist implementations (including our own within security) allow direct IPs as well as CIDR ranges. One thing to note, though, is that in those cases a single range of ips is not being defined, but a list of allowed whitelists. My main concern would be a user accidentally leaving off the suffix, unknowingly only indexing a single ip within a range instead of an intended range. Perhaps an alternative would be to support a single value key within an object for a range field, as a shortcut for specifying both ends of the range.

[ZLightning]

My main concern would be a user accidentally leaving off the suffix, unknowingly only indexing a single ip within a range instead of an intended range.

I'll admit there is a risk that users might accidentally leave off the block size in a range, but does that mean it should be required to put a + in front of a positive number so you can be sure that the person didn't leave off a - on a negative number?

The bigger threat I see is that someone intends to index a single IP and leaves off the /32 (or /128 for IPv6) and then ignores/misses the error, perhaps in a bulk indexing request. In this case, the data is lost entirely, whereas with an accidental listing of a single IP where a range was intended, the listing for the single IP would still be better than not listing anything. Note, I am not suggesting that ignoring errors is a good idea, but rather that data preservation should take precedence over forcing extra verbosity to prevent users from making mistakes.

[jtibshirani]

I'm going to mark this for discussion again so that @rjernst has the chance to weigh in. The main question seems to be whether we want to favor flexibility by default, and risk users accidentally indexing single IPs into the range field.

[eskibars]

I personally think this type of mistake is a very low risk as long as we aren't doing very lenient parsing.

[rjernst]

After a followup fix-it-day discussion, we have decided against this proposal. In addition to the already existing ability to pass a single value by using /32 or by specifying both gte and lte (as works for any range field type), the possibility to muddy the user intention is too great. For example, if we were to start accepting these values without the suffix, one might suggest masks should be implicit based on significant bits, eg interpreting 192.168.0.0 as 192.168.0.0/16. Saving a few characters input is not worth the confusion in interpretation.