Deploying the first API boundary nodes

Governance
1

Hello everyone,

I’m pleased to announce that we’re nearing the deployment of the first API boundary nodes under NNS control. Before we proceed, we need to submit a proposal for monitoring access from DFINITY datacenters. This will allow us to observe the health of the API boundary nodes and address any issues.

Following this, we will propose converting some unassigned nodes into API boundary nodes. This marks the first step towards the new boundary node architecture, detailed here.

Feel free to ask any questions. We will update this thread with the proposals as we submit them.

19 Likes
2

We have just submitted the proposal to allow access to all “monitoring and observability” ports from the DFINITY datacenters. You can find proposal 130319 here and vote on it.

In particular, this proposal provides access to the following ports:

  • 7070: orchestrator dashboard
  • 9091: orchestrator metrics
  • 9100: node exporter metrics
  • 9324: ic-boundary metrics
  • 19100: metrics proxy metrics
  • 19531: systemd-journal-gatewayd (logs)

For now this firewall rule has no effect, but will be used as soon as the first API boundary node is deployed.

5 Likes
3

And we have just submitted the proposal to turn two unassigned nodes into API boundary nodes. You can find proposal 130337 here and vote on it.

5 Likes
4

We have liftoff! :rocket:

Both proposals have been adopted and the first two API boundary nodes are live! Right now, they are not yet taking any production traffic as that is still routed through the existing boundary nodes. However, as we make progress towards the new boundary node architecture, we will gradually add more API boundary nodes and start shifting traffic to them.

The first two API boundary nodes are live and are happy to serve any requests you might have. If you want to try it out, you can for example query the total ckBTC supply using the follow command:

dfx canister call mxzaz-hqaaa-aaaar-qaada-cai icrc1_total_supply '()' --network https://bc1-dll02.blockchaindevlabs.com --query

or

dfx canister call mxzaz-hqaaa-aaaar-qaada-cai icrc1_total_supply '()' --network https://br1-dll01.aviatelabs.co --query
8 Likes
5

Awesome, congralutations to the team! :partying_face:

2 Likes
6

Why can’t I open https://bc1-dll02.blockchaindevlabs.com

7

The API boundary nodes only serve the API endpoints und /api/v2/... as defined in the interface spec.

When you try to open the root, you just get a 404 back. You can see it the best on the command line:

$ curl -sLv https://bc1-dll02.blockchaindevlabs.com
...
* Server certificate:
*  subject: CN=bc1-dll02.blockchaindevlabs.com
*  start date: Jun 13 08:16:02 2024 GMT
*  expire date: Sep 11 08:16:01 2024 GMT
*  subjectAltName: host "bc1-dll02.blockchaindevlabs.com" matched cert's "bc1-dll02.blockchaindevlabs.com"
*  issuer: C=US; O=Let's Encrypt; CN=E6
*  SSL certificate verify ok.
...
< HTTP/2 404
< content-length: 0
< date: Thu, 13 Jun 2024 11:57:59 GMT
<
* Connection #0 to host bc1-dll02.blockchaindevlabs.com left intact
8

What is the difference between bc1-dll02.blockchaindevlabs.com and icp0.io

9

bc1-dll02.blockchaindevlabs.com is the domain of an API boundary node and icp0.io is a domain of today’s boundary nodes.

I guess that doesn’t really help much. So what does it mean:
We are redesigning the edge of the Internet Computer. Today, there are boundary nodes (or “today’s boundary nodes”) and they do mainly two things:

  1. translate your browser’s HTTP requests into API calls;
  2. route API calls to the right subnet and replica.

This is what is running under icp0.io and ic0.app. These domains serve both purposes: you can directly access canisters using CANISTER_ID.icp0.io and you can directly submit API calls using icp0.io/api/v2/....

The new edge will, at a very high level, split today’s boundary nodes into two entities: API boundary nodes and HTTP gateways. API boundary nodes only serve the API endpoints, while the HTTP gateways mainly provide the capability to access canisters directly from your browser.

Ultimately, bc1-dll02.blockchaindevlabs.com/api/v2/... serves the same purpose as icp0.io/api/v2....

For more information about the new edge of the Internet Computer, check this thread about the boundary node roadmap.

2 Likes
10

Hi @rbirkner, thank you for all of the awesome work you and your team have been doing :folded_hands:

As of today, if a user would like to access a website hosted on the IC, what are their options for accessing it in a way that is least susceptible to an attack. Assume the user signs into the site and deals with large sums of crypto (so if an attacker can control what the user sees on the frontend and how it interacts with the backend, then they can control what happens to the funds).

Take https://waterneuron.fi/ as an example, which is also accessible via https://n3i53-gyaaa-aaaam-acfaq-cai.icp0.io/

1 Like
11

Hey @Lorimer

Thank you for the kind words! I really appreciate the support. :folded_hands:

Regarding your question, there are three ways to access canister frontends on the IC via the HTTP Gateway Protocol:

  • The most convenient option is using one of the DFINITY-operated HTTP Gateways, allowing users to access sites directly from their browsers without extra setup.
  • If users prefer not to rely on DFINITY’s gateways, other operators or a dapp team (e.g., WaterNeuron) could run its own HTTP gateway (either catch-all like DFINITY or dapp specific). This requires additional infrastructure and maintenance. Users still need to trust these operators, but they have more options.
  • For maximum control, users can run a local HTTP gateway, eliminating reliance on external parties. A proof-of-concept can be found here: HTTP proxy.

If you only need to do API canister calls, you can directly target the API boundary nodes using the agents and completely bypass any centralized infrastructure.

3 Likes
12

Thanks @rbirkner :slightly_smiling_face: What sort of trust assumptions need to be made about the boundary node that gets used? Presumably the node could act as a man in the middle and modify the request :thinking:

13

Good question:

HTTP Gateways need to be fully trusted as they take your HTTP request, transform it into an IC API request (usually query call), verify the certification of the query response, and then turn the query response into an HTTP response. The HTTP gateway can modify, inject, drop at any step of that. Here, you are trading convenience for security: you are trusting the gateway operator.

API boundary nodes on the other hand don’t have to be trusted. The worst an API BN can do, is to drop or delay your request or the corresponding response. This is the case as you as a client sign the request and the replica signs the response.

1 Like
14

Thanks @rbirkner! I could definitely do with diving deeper into this topic. Ideally I’d love there to be a way for all users to be able to depend on IC websites, even the less tech savvy ones (without having to make trust assumptions). I have some additional thoughts / questions.

Presumably if there are multiple domain names, and each one is controlled by a different entity, one could validate that all domains serve binary equivalent assets (given certain requests), providing DNS consensus. Is this an approach you could see working?

If there’s no need for any significant trust assumptions about boundary nodes, is it not possible to extend this safety to http gateways? For arguments sake, if an API call to a boundary node returned a byte stream representing and HTML page (and/or other assets), couldn’t this be served up by the browser (theoretically speaking)? I guess I’m trying to understand why the security that’s offered for API calls to boundary nodes cannot also be applied for HTTP request/responses.

Given that DNS is all about not having to memorise an IP address, theoretically a user could just visit the IP address directly, rather than entering a domain name. I guess that only gets you this far though → https://193.118.59.140/

I’m mostly thinking out loud, but I’d really appreciate your insights relating to these thoughts.

1 Like
15

The problem is that for this you always need to rely on Web2 technology and this is usually inherently centralized (e.g., look at DNS).

That’s an option, but there is even a simpler one: when you make a request through an HTTP gateway, the HTTP gateway will “forward” the certification of the data to you as part of the header. That’s the ic-certificate header. However, all of these approaches require some processing client-side and don’t work out of the box with a standard browser. So again, not something for a “normal” user.

It’s all about convenience: The HTTP gateway makes the IC API request for you. As long as you don’t make it yourself, you need to trust the gateway. You could integrate the HTTP gateway into the browser (i.e., similar to the IPFS integrations brave has). One or two years ago, we looked into that, but we stopped the effort as browser extensions are too limited and a direct browser integration doesn’t really make sense as long as it won’t be a mainstream browser with high adoption.

2 Likes
16

Thanks @rbirkner, does this describe the current behaviour or a plan for the future?

With this it should be trivial to validate responses in any old browser using a fairly simple browser extension (unless I’m missing something).

17

Yes, this is the current behavior. You can see it yourself when you just look at the headers returned by a request:

$ curl -sv https://internetcomputer.org
..
< ic-certificateexpression: default_certification(ValidationArgs{certification: Certification{no_request_certification: Empty{}, response_certification: ResponseCertification{certified_response_headers: ResponseHeaderList{headers: ["content-type", "X-Content-Type-Options", "Strict-Transport-Security", "Permissions-Policy", "X-Frame-Options", "X-XSS-Protection", "Content-Security-Policy", "Referrer-Policy"]}}}})
< ic-certificate: version=2, certificate=:2dn3o2R0cm...
...

Of course, you could use a very old browser with less restrictive APIs, but what would you get from that? Old browsers are missing many security patches, you still need to install a specific program, you might lack your other extensions, bookmarks etc. In that case, might as well just use the http proxy, which does everything you want and works with any browser.

1 Like
18

Thanks @rbirkner. So if a bad actor were able to repoint a trusted domain name to serve up a fake / adjusted version of a dapp frontend, this would be detectable by any user that decides to check the validity of the certificate in the header?

1 Like
19

Yes exactly, if a user checks the certification, they can detect such cases.

1 Like
20

Great! Are there any examples of frontend code that performs this check that can be pointed to?

I understand that a frontend validating its own certificate is somewhat pointless. Instead, I’m just thinking a snippet of js that could run in the browser’s dev console would do the trick for anyone who wants to check.

1 Like