3 ms·

I have a few questions: - Are there any benchmarks? - Examples are focused around TCP inlet to TCP outlet. Any way you can add more complicated examples? I ta

by 0x457 4y ago

I have a few questions: - Are there any benchmarks? - Examples are focused around TCP inlet to TCP outlet. Any way you can add more complicated examples? I take I can have a TCP inlet and a Worker that would would receive TCP stream wrapped into Routed, then I can unwrap it and work with it kinda as if it was “normal” TCP. I’m curious about second one because while connecting some clients to legacy is fun, it’s more fun when services connected directly. For example, I want some kind of RPC or database without “external” TCP connection from node to database.

mwadhwa 4y ago
Thanks for trying out the examples: 1. No benchmarks yet. We'd welcome contributions & research in that area. 2. Here's an example of using the TCP transport without using an Inlet / Outlet. https://github.com/build-trust/ockam/blob/develop/documentation/guides/rust/get-started/05-secure-channel/README.md#secure-channel https://github.com/build-trust/ockam/blob/develop/documentat... Give it a try. Would love to know if that fits what you're going for.
- 0x457 4y ago
  That's close to what I was thinking. I guess a message here could be just a bag of bytes, and then you can plug listener side into `tower` stack. Can't exactly wrap my head around access control here. In this example, let's assume I'm using a proper policy and not `TrustEveryonePolicy`. What's stopping someone from using this route: route![(TCP, "localhost:3000"), (TCP, "localhost:4000"), "echoer"]; in this example? I see that Worker has `is_authorized` method and even before that method executed `Mailbox` also uses, so I see how to avoid issue from above. However, middle node would forward any traffic without any questions unless https://docs.rs/ockam/latest/ockam/struct.Context.html#method.new_repeater https://docs.rs/ockam/latest/ockam/struct.Context.html#metho... is used? Then I'm curious if middle node will be able to use https://docs.rs/ockam/latest/ockam/access_control/struct.IdentityIdAccessControl.html https://docs.rs/ockam/latest/ockam/access_control/struct.Ide... given that it doesn't know much about the channel? I'm just working on something that could use this, but right now, we use wireguard + nftables + convoluted routing policies + TLS. I would go far to not use TLS and manage X.509 infrastructure and hopefully avoid double encryption.
  - mattgreg 4y ago
    would you like to schedule some time with us to dig into this further. This sounds really interesting and pretty close to things we've seen others do before. To move this off of HN and to a channel that we look at more regularly, I'd like to suggest a couple alts: 1) GitHub Discussions: https://github.com/build-trust/ockam/discussions/categories/q-a https://github.com/build-trust/ockam/discussions/categories/... 2) We can schedule a zoom call: https://www.ockam.io/contact/form https://www.ockam.io/contact/form

by 0x457 4y ago

mwadhwa 4y ago

Thanks for trying out the examples: 1. No benchmarks yet. We'd welcome contributions & research in that area. 2. Here's an example of using the TCP transport without using an Inlet / Outlet. https://github.com/build-trust/ockam/blob/develop/documentation/guides/rust/get-started/05-secure-channel/README.md#secure-channel https://github.com/build-trust/ockam/blob/develop/documentat... Give it a try. Would love to know if that fits what you're going for.

0x457 4y ago
That's close to what I was thinking. I guess a message here could be just a bag of bytes, and then you can plug listener side into `tower` stack. Can't exactly wrap my head around access control here. In this example, let's assume I'm using a proper policy and not `TrustEveryonePolicy`. What's stopping someone from using this route: route![(TCP, "localhost:3000"), (TCP, "localhost:4000"), "echoer"]; in this example? I see that Worker has `is_authorized` method and even before that method executed `Mailbox` also uses, so I see how to avoid issue from above. However, middle node would forward any traffic without any questions unless https://docs.rs/ockam/latest/ockam/struct.Context.html#method.new_repeater https://docs.rs/ockam/latest/ockam/struct.Context.html#metho... is used? Then I'm curious if middle node will be able to use https://docs.rs/ockam/latest/ockam/access_control/struct.IdentityIdAccessControl.html https://docs.rs/ockam/latest/ockam/access_control/struct.Ide... given that it doesn't know much about the channel? I'm just working on something that could use this, but right now, we use wireguard + nftables + convoluted routing policies + TLS. I would go far to not use TLS and manage X.509 infrastructure and hopefully avoid double encryption.
- mattgreg 4y ago
  would you like to schedule some time with us to dig into this further. This sounds really interesting and pretty close to things we've seen others do before. To move this off of HN and to a channel that we look at more regularly, I'd like to suggest a couple alts: 1) GitHub Discussions: https://github.com/build-trust/ockam/discussions/categories/q-a https://github.com/build-trust/ockam/discussions/categories/... 2) We can schedule a zoom call: https://www.ockam.io/contact/form https://www.ockam.io/contact/form