Summary

  • RIPE’s aut-num object for AS31444, SEANET-AS, points to SeaExpress Ltd.; at the 28 August capture it originated ten visible IPv4 prefixes covering 9,216 addresses and was visible to all 327 IPv4 RIS peers returned by RIPEstat.
  • The ten prefix records do not follow one attribution pattern: six blocks totalling 6,912 addresses name or describe SeaExpress, three totalling 1,280 addresses name SeaTelecom, and one 1,024-address block is described only as a small-client network.
  • Every tested AS31444/prefix pair returned RPKI unknown with no validating ROA. That is a public authorisation gap, not an invalid verdict, hijack evidence or a measure of network reliability.

SeaExpress is easier to identify than the route authority behind every address it originates. RIPE organisation ORG-SL17-RIPE names SeaExpress Ltd., records Russian registration number 1027809233649, classifies it as an LIR and lists MNT-SEANET. The company’s own legal-details page gives the same OGRN for ООО «Морской Экспресс». RIPE’s AS31444 object is named SEANET-AS, points back to that organisation and publishes an import-and-export policy under the same maintainer.

The public identity chain continues outside RIPE. PeeringDB’s AS31444 record is named SeaExpress and lists seaexpress.ru. The captured page at that address redirects visitors to seatelecom.ru; that site identifies the provider and legal entity as Морской Экспресс and uses seaexpress.ru email addresses. This establishes a public web and registry trail. It does not, by itself, establish the legal relationship between SeaExpress, SeaTelecom Nord-West or every other organisation found in the route records.

The company site gives the route data a business context. It markets dedicated-line Internet access using FTTB or FTTP, routed and unrouted Ethernet channels, synchronous channels and assistance with autonomous-system registration. Its leased-channel page claims capacity up to 10 Gbit/s. It also says services run on its own fibre network, important fibre sections are redundant, backbone channels are monitored continuously, every communications node has UPS equipment with up to eight hours of autonomous operation, and support is available around the clock.

Those statements identify what SeaExpress asks a customer to trust. They are not an audited SLA. The public pages supply no node inventory, route-diversity map, common-duct analysis, UPS test results, restoration distribution or incident ledger. “Up to eight hours” is a design assertion, not proof that every relevant load achieved that runtime during an outage.

RIPEstat’s captured control-plane view is precise in a different way. AS31444 originated ten IPv4 prefixes covering 9,216 addresses, was seen by 327 of 327 returned IPv4 RIS peers and had 36 observed neighbours. No IPv6 prefix was visible in that result. These numbers describe the observation set at the capture time; they do not count customers, measure utilisation, prove reachability from every network or validate local access service.

The ten blocks split into three public-record patterns:

Record pattern Prefixes IPv4 addresses
Records naming ORG-SL17-RIPE or describing SeaExpress 6 6,912
Records naming SeaTelecom’s ORG-SNL56-RIPE 3 1,280
RU-SEANET-ABONENTS / “Clients with small network”, with no organisation field in the captured result 1 1,024

All ten captured IRR results include origin 31444 and maintainer MNT-SEANET. That consistency matters: it shows a common public routing-policy surface. It still does not transfer title to the address space or identify the human and organisational controls behind a production route change.

One record makes the distinction especially visible. The allocation covering 185.253.104.0/22 names SeaExpress’s ORG-SL17-RIPE, while route objects for that space name ORG-PL468-RIPE, describe a Scrollnet network, use origin 31444 and retain MNT-SEANET. A reader can observe all of those fields without learning the legal, commercial or operational agreement that connects them.

RPKI adds another boundary. Each of the ten tested origin/prefix pairs returned unknown and no validating ROA. “Unknown” means the validator found no applicable authorisation in the captured result. It does not mean the route was invalid, unauthorised under every other mechanism, leaked or hijacked. IRR objects, contracts and operational access can exist without a visible ROA; none is interchangeable with the others.

The practical conclusion is narrower than a security score. SeaExpress operates the public identity attached to AS31444 and presents concrete service and resilience claims. Its route surface also contains address records associated with more than one organisation and no validating ROAs in the tested view. Buyers and counterparties therefore need a prefix-level authority register: resource holder, permitted user, IRR maintainer, BGP origin, ROA controller, physical operator, retail provider and incident owner.

Primary source register: S01, S02, S03, S04, S05, S06, S07, S08, S09, S10, S11, S12, S13, S14, S15, S16, S17, S18, S19, S20, S21, S22, S23, S24, S25, S26, S27, S28, S29, S30, S31, S32.