[bug/providers] PrefixListParser accepts /0 (default route) and /33+ from peer-supplied URLs — route leak

[ruhex]

Bug

PrefixListParser.Parse validates the prefix length only as a byte — 0 and 33–255 are accepted, and host bits are never masked:

// BGPLite.Providers/PrefixListParser.cs:26-29
if (!byte.TryParse(lengthStr, out byte length))   // accepts 0 and 33..255
    continue;
// ... IPAddress.TryParse(prefix, ...) then store as-is, no host-bit masking

This parser feeds both HttpPrefixProvider (peer-supplied URLs via #147) and FilePrefixProvider (operator nets.txt). The API-layer ParseCustomPrefix (#123) was hardened with a 0..32 range check, but the providers-layer parser was not.

Impact

• Default-route leak: a single line 0.0.0.0/0 in a peer-supplied URL list advertises the entire IPv4 space to all peers — a catastrophic route leak. /0 is silently accepted (the aggregator's 1UL << 32 path also special-cases it).
• Nonsensical lengths: 33–255 are stored and propagated downstream.
• Host bits not masked: 10.0.0.1/8 is stored verbatim instead of normalizing to 10.0.0.0/8, producing duplicate/overlapping routes and breaking longest-prefix-match / dedup.
• All silent — logged nowhere.

Fix

• Reject out-of-range lengths: if (length > 32) { log/continue; }.
• Decide explicitly on /0: either reject (route-server should not originate a default) or require an operator opt-in flag.
• Mask host bits: prefix &= (length == 0) ? 0 : (0xFFFFFFFFu << (32 - length)); before storing.
• Decide on IPv6 handling (currently the parser is IPv4-only via IPAddress.Parse semantics — make that explicit or extend).

Scope

S. Provider-layer; covered by extending PrefixListParserTests with /0, /33, host-bits-set, and BOM cases.

Refs: #123 (API-layer CIDR validation — the analogue that was fixed), #147 (peer-supplied URLs — the surface that makes this dangerous).