Edge router on the client side

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Edge router on the client side

Petrenko, Vadim
Hi Qpid developers,

We’re considering this possibility:

Containerize a preconfigured Edge router (possibly together with Artemis) and give it to an application team.

The application team will then deploy this container in their environment -> the Edge router will connect to a couple Interior routers in our Core network -> the client application will connect to the Edge router in the container using standard libraries like Qpid-JMS.

We expect this to allow easy scaling up of clients. We also want to attach a broker to the edge router in case messages need to be buffered (but this is client specific and does not belong to the generic core network setup).

Does this setup look reasonable from a Qpid developer’s point of view?
Maybe there are some pitfalls to watch out for? Especially exposing Interior routers to the world.


Thanks!



________________________________

Deze e-mail, inclusief eventuele bijlagen, is uitsluitend bestemd voor (gebruik door) de geadresseerde. De e-mail kan persoonlijke of vertrouwelijke informatie bevatten. Openbaarmaking, vermenigvuldiging, verspreiding en/of verstrekking van (de inhoud van) deze e-mail (en eventuele bijlagen) aan derden is uitdrukkelijk niet toegestaan. Indien u niet de bedoelde geadresseerde bent, wordt u vriendelijk verzocht degene die de e-mail verzond hiervan direct op de hoogte te brengen en de e-mail (en eventuele bijlagen) te vernietigen.

Informatie vennootschap<http://www.ns.nl/emaildisclaimer>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Edge router on the client side

Ted Ross
On Fri, Nov 20, 2020 at 5:32 AM Petrenko, Vadim <[hidden email]>
wrote:

> Hi Qpid developers,
>
> We’re considering this possibility:
>
> Containerize a preconfigured Edge router (possibly together with Artemis)
> and give it to an application team.
>
> The application team will then deploy this container in their environment
> -> the Edge router will connect to a couple Interior routers in our Core
> network -> the client application will connect to the Edge router in the
> container using standard libraries like Qpid-JMS.
>
> We expect this to allow easy scaling up of clients. We also want to attach
> a broker to the edge router in case messages need to be buffered (but this
> is client specific and does not belong to the generic core network setup).
>
> Does this setup look reasonable from a Qpid developer’s point of view?
> Maybe there are some pitfalls to watch out for? Especially exposing
> Interior routers to the world.
>

This is a good use case, and one that I think is appropriate for edge
routers.

If you are going to deploy your interior routers in a public place, I think
you would want strong security (mutual TLS) on those open ports.  Can you
issue certificates to your application teams in the form of secrets so they
can securely connect to your network?


>
>
> Thanks!
>
>
>
> ________________________________
>
> Deze e-mail, inclusief eventuele bijlagen, is uitsluitend bestemd voor
> (gebruik door) de geadresseerde. De e-mail kan persoonlijke of
> vertrouwelijke informatie bevatten. Openbaarmaking, vermenigvuldiging,
> verspreiding en/of verstrekking van (de inhoud van) deze e-mail (en
> eventuele bijlagen) aan derden is uitdrukkelijk niet toegestaan. Indien u
> niet de bedoelde geadresseerde bent, wordt u vriendelijk verzocht degene
> die de e-mail verzond hiervan direct op de hoogte te brengen en de e-mail
> (en eventuele bijlagen) te vernietigen.
>
> Informatie vennootschap<http://www.ns.nl/emaildisclaimer>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Edge router on the client side

Chuck Rolke
Also, do not build the image with certificates embedded within it.
Find a way to inject the connection secrets into the container
as it is launched.


----- Original Message -----

> From: "Ted Ross" <[hidden email]>
> To: [hidden email]
> Sent: Friday, November 20, 2020 10:53:45 AM
> Subject: Re: Edge router on the client side
>
> On Fri, Nov 20, 2020 at 5:32 AM Petrenko, Vadim <[hidden email]>
> wrote:
>
> > Hi Qpid developers,
> >
> > We’re considering this possibility:
> >
> > Containerize a preconfigured Edge router (possibly together with Artemis)
> > and give it to an application team.
> >
> > The application team will then deploy this container in their environment
> > -> the Edge router will connect to a couple Interior routers in our Core
> > network -> the client application will connect to the Edge router in the
> > container using standard libraries like Qpid-JMS.
> >
> > We expect this to allow easy scaling up of clients. We also want to attach
> > a broker to the edge router in case messages need to be buffered (but this
> > is client specific and does not belong to the generic core network setup).
> >
> > Does this setup look reasonable from a Qpid developer’s point of view?
> > Maybe there are some pitfalls to watch out for? Especially exposing
> > Interior routers to the world.
> >
>
> This is a good use case, and one that I think is appropriate for edge
> routers.
>
> If you are going to deploy your interior routers in a public place, I think
> you would want strong security (mutual TLS) on those open ports.  Can you
> issue certificates to your application teams in the form of secrets so they
> can securely connect to your network?
>
>
> >
> >
> > Thanks!
> >
> >
> >
> > ________________________________
> >
> > Deze e-mail, inclusief eventuele bijlagen, is uitsluitend bestemd voor
> > (gebruik door) de geadresseerde. De e-mail kan persoonlijke of
> > vertrouwelijke informatie bevatten. Openbaarmaking, vermenigvuldiging,
> > verspreiding en/of verstrekking van (de inhoud van) deze e-mail (en
> > eventuele bijlagen) aan derden is uitdrukkelijk niet toegestaan. Indien u
> > niet de bedoelde geadresseerde bent, wordt u vriendelijk verzocht degene
> > die de e-mail verzond hiervan direct op de hoogte te brengen en de e-mail
> > (en eventuele bijlagen) te vernietigen.
> >
> > Informatie vennootschap<http://www.ns.nl/emaildisclaimer>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: Edge router on the client side

Petrenko, Vadim
Thank you guys for your responses.

What bothers me is that such an Edge router placed at the client will have all the topology information about every single other router in the network, how they are interconnected, etc., as it has to participate in the routing data exchange. It will even expose the Qpid console! Will show network throughput, etc. Some data a client should have no access to imo.

Some of these clients in our case might have intermittent connections over weak links, and there could be quite a few of them (i.e. several thousands clients). So this routing information would have to be exchanged every time a client's Edge router connects to the core network.

Do you have any ideas how to mitigate this or maybe this shouldn't actually deserve any serious concerns?

Thank you.

-----Original Message-----
From: Chuck Rolke <[hidden email]>
Sent: vrijdag 20 november 2020 17:57
To: [hidden email]
Subject: Re: Edge router on the client side

Also, do not build the image with certificates embedded within it.
Find a way to inject the connection secrets into the container as it is launched.


----- Original Message -----

> From: "Ted Ross" <[hidden email]>
> To: [hidden email]
> Sent: Friday, November 20, 2020 10:53:45 AM
> Subject: Re: Edge router on the client side
>
> On Fri, Nov 20, 2020 at 5:32 AM Petrenko, Vadim <[hidden email]>
> wrote:
>
> > Hi Qpid developers,
> >
> > We’re considering this possibility:
> >
> > Containerize a preconfigured Edge router (possibly together with Artemis)
> > and give it to an application team.
> >
> > The application team will then deploy this container in their environment
> > -> the Edge router will connect to a couple Interior routers in our Core
> > network -> the client application will connect to the Edge router in the
> > container using standard libraries like Qpid-JMS.
> >
> > We expect this to allow easy scaling up of clients. We also want to attach
> > a broker to the edge router in case messages need to be buffered (but this
> > is client specific and does not belong to the generic core network setup).
> >
> > Does this setup look reasonable from a Qpid developer’s point of view?
> > Maybe there are some pitfalls to watch out for? Especially exposing
> > Interior routers to the world.
> >
>
> This is a good use case, and one that I think is appropriate for edge
> routers.
>
> If you are going to deploy your interior routers in a public place, I think
> you would want strong security (mutual TLS) on those open ports.  Can you
> issue certificates to your application teams in the form of secrets so they
> can securely connect to your network?
>
>
> >
> >
> > Thanks!
> >
> >
> >
> > ________________________________
> >
> > Deze e-mail, inclusief eventuele bijlagen, is uitsluitend bestemd voor
> > (gebruik door) de geadresseerde. De e-mail kan persoonlijke of
> > vertrouwelijke informatie bevatten. Openbaarmaking, vermenigvuldiging,
> > verspreiding en/of verstrekking van (de inhoud van) deze e-mail (en
> > eventuele bijlagen) aan derden is uitdrukkelijk niet toegestaan. Indien u
> > niet de bedoelde geadresseerde bent, wordt u vriendelijk verzocht degene
> > die de e-mail verzond hiervan direct op de hoogte te brengen en de e-mail
> > (en eventuele bijlagen) te vernietigen.
> >
> > Informatie vennootschap<http://www.ns.nl/emaildisclaimer>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]


________________________________

Deze e-mail, inclusief eventuele bijlagen, is uitsluitend bestemd voor (gebruik door) de geadresseerde. De e-mail kan persoonlijke of vertrouwelijke informatie bevatten. Openbaarmaking, vermenigvuldiging, verspreiding en/of verstrekking van (de inhoud van) deze e-mail (en eventuele bijlagen) aan derden is uitdrukkelijk niet toegestaan. Indien u niet de bedoelde geadresseerde bent, wordt u vriendelijk verzocht degene die de e-mail verzond hiervan direct op de hoogte te brengen en de e-mail (en eventuele bijlagen) te vernietigen.

Informatie vennootschap<http://www.ns.nl/emaildisclaimer>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Edge router on the client side

Ken Giusti
On Mon, Nov 23, 2020 at 7:32 AM Petrenko, Vadim <[hidden email]>
wrote:

> Thank you guys for your responses.
>
> What bothers me is that such an Edge router placed at the client will have
> all the topology information about every single other router in the
> network, how they are interconnected, etc., as it has to participate in the
> routing data exchange. It will even expose the Qpid console! Will show
> network throughput, etc. Some data a client should have no access to imo.
>
> Some of these clients in our case might have intermittent connections over
> weak links, and there could be quite a few of them (i.e. several thousands
> clients). So this routing information would have to be exchanged every time
> a client's Edge router connects to the core network.
>
> Do you have any ideas how to mitigate this or maybe this shouldn't
> actually deserve any serious concerns?
>
>
Actually, the edge routers do not fully participate in the route table
exchange.  Edge routers are exposed to only those addresses needed by the
clients attached to the edge itself.  Specifically, when a subscriber
client attaches to the edge, the edge notifies its attached interior router
of the subscription address and leaves it to the interior router to
propagate that on behalf of the edge router.  Similar behavior for
producing clients - the edge queries its interior router for route details
for only the producer's destination address.

So the amount of routing information that needs to be exchanged between the
edge and its interior is minimal and probably is not something to be
concerned about.

-K



> Thank you.
>
> -----Original Message-----
> From: Chuck Rolke <[hidden email]>
> Sent: vrijdag 20 november 2020 17:57
> To: [hidden email]
> Subject: Re: Edge router on the client side
>
> Also, do not build the image with certificates embedded within it.
> Find a way to inject the connection secrets into the container as it is
> launched.
>
>
> ----- Original Message -----
> > From: "Ted Ross" <[hidden email]>
> > To: [hidden email]
> > Sent: Friday, November 20, 2020 10:53:45 AM
> > Subject: Re: Edge router on the client side
> >
> > On Fri, Nov 20, 2020 at 5:32 AM Petrenko, Vadim <[hidden email]>
> > wrote:
> >
> > > Hi Qpid developers,
> > >
> > > We’re considering this possibility:
> > >
> > > Containerize a preconfigured Edge router (possibly together with
> Artemis)
> > > and give it to an application team.
> > >
> > > The application team will then deploy this container in their
> environment
> > > -> the Edge router will connect to a couple Interior routers in our
> Core
> > > network -> the client application will connect to the Edge router in
> the
> > > container using standard libraries like Qpid-JMS.
> > >
> > > We expect this to allow easy scaling up of clients. We also want to
> attach
> > > a broker to the edge router in case messages need to be buffered (but
> this
> > > is client specific and does not belong to the generic core network
> setup).
> > >
> > > Does this setup look reasonable from a Qpid developer’s point of view?
> > > Maybe there are some pitfalls to watch out for? Especially exposing
> > > Interior routers to the world.
> > >
> >
> > This is a good use case, and one that I think is appropriate for edge
> > routers.
> >
> > If you are going to deploy your interior routers in a public place, I
> think
> > you would want strong security (mutual TLS) on those open ports.  Can you
> > issue certificates to your application teams in the form of secrets so
> they
> > can securely connect to your network?
> >
> >
> > >
> > >
> > > Thanks!
> > >
> > >
> > >
> > > ________________________________
> > >
> > > Deze e-mail, inclusief eventuele bijlagen, is uitsluitend bestemd voor
> > > (gebruik door) de geadresseerde. De e-mail kan persoonlijke of
> > > vertrouwelijke informatie bevatten. Openbaarmaking, vermenigvuldiging,
> > > verspreiding en/of verstrekking van (de inhoud van) deze e-mail (en
> > > eventuele bijlagen) aan derden is uitdrukkelijk niet toegestaan.
> Indien u
> > > niet de bedoelde geadresseerde bent, wordt u vriendelijk verzocht
> degene
> > > die de e-mail verzond hiervan direct op de hoogte te brengen en de
> e-mail
> > > (en eventuele bijlagen) te vernietigen.
> > >
> > > Informatie vennootschap<http://www.ns.nl/emaildisclaimer>
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [hidden email]
> > > For additional commands, e-mail: [hidden email]
> > >
> > >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
> ________________________________
>
> Deze e-mail, inclusief eventuele bijlagen, is uitsluitend bestemd voor
> (gebruik door) de geadresseerde. De e-mail kan persoonlijke of
> vertrouwelijke informatie bevatten. Openbaarmaking, vermenigvuldiging,
> verspreiding en/of verstrekking van (de inhoud van) deze e-mail (en
> eventuele bijlagen) aan derden is uitdrukkelijk niet toegestaan. Indien u
> niet de bedoelde geadresseerde bent, wordt u vriendelijk verzocht degene
> die de e-mail verzond hiervan direct op de hoogte te brengen en de e-mail
> (en eventuele bijlagen) te vernietigen.
>
> Informatie vennootschap<http://www.ns.nl/emaildisclaimer>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

--
-K
Reply | Threaded
Open this post in threaded view
|

Re: Edge router on the client side

Ganesh Murthy
In reply to this post by Petrenko, Vadim
On Mon, Nov 23, 2020 at 7:37 AM Petrenko, Vadim <[hidden email]>
wrote:

> Thank you guys for your responses.
>
> What bothers me is that such an Edge router placed at the client will have
> all the topology information about every single other router in the
> network, how they are interconnected, etc., as it has to participate in the
> routing data exchange. It will even expose the Qpid console! Will show
> network throughput, etc. Some data a client should have no access to imo.
>

> Some of these clients in our case might have intermittent connections over
> weak links, and there could be quite a few of them (i.e. several thousands
> clients). So this routing information would have to be exchanged every time
> a client's Edge router connects to the core network.
>
When the edge router connects to a router network (to an interior router),
the router network thinks of the edge router as just just another client
albeit a "special" client. The edge router itself is not part of the
network. Whenever a qdstat client asks the edge router for the topology of
the router network, it in turn asks the interior it is connected to for
that information. That being said, I wonder if you can use some policy
restrictions on the interior router to block all management requests
(requests to $management address) coming from the edge router (I would let
the policy experts weigh in on this). This would effectively block the edge
router from accessing any sensitive information about the router network
but still allowing qdstat/qdmanage  to work within the context of the edge
router.

>
> Do you have any ideas how to mitigate this or maybe this shouldn't
> actually deserve any serious concerns?
>
> Thank you.
>
> -----Original Message-----
> From: Chuck Rolke <[hidden email]>
> Sent: vrijdag 20 november 2020 17:57
> To: [hidden email]
> Subject: Re: Edge router on the client side
>
> Also, do not build the image with certificates embedded within it.
> Find a way to inject the connection secrets into the container as it is
> launched.
>
>
> ----- Original Message -----
> > From: "Ted Ross" <[hidden email]>
> > To: [hidden email]
> > Sent: Friday, November 20, 2020 10:53:45 AM
> > Subject: Re: Edge router on the client side
> >
> > On Fri, Nov 20, 2020 at 5:32 AM Petrenko, Vadim <[hidden email]>
> > wrote:
> >
> > > Hi Qpid developers,
> > >
> > > We’re considering this possibility:
> > >
> > > Containerize a preconfigured Edge router (possibly together with
> Artemis)
> > > and give it to an application team.
> > >
> > > The application team will then deploy this container in their
> environment
> > > -> the Edge router will connect to a couple Interior routers in our
> Core
> > > network -> the client application will connect to the Edge router in
> the
> > > container using standard libraries like Qpid-JMS.
> > >
> > > We expect this to allow easy scaling up of clients. We also want to
> attach
> > > a broker to the edge router in case messages need to be buffered (but
> this
> > > is client specific and does not belong to the generic core network
> setup).
> > >
> > > Does this setup look reasonable from a Qpid developer’s point of view?
> > > Maybe there are some pitfalls to watch out for? Especially exposing
> > > Interior routers to the world.
> > >
> >
> > This is a good use case, and one that I think is appropriate for edge
> > routers.
> >
> > If you are going to deploy your interior routers in a public place, I
> think
> > you would want strong security (mutual TLS) on those open ports.  Can you
> > issue certificates to your application teams in the form of secrets so
> they
> > can securely connect to your network?
> >
> >
> > >
> > >
> > > Thanks!
> > >
> > >
> > >
> > > ________________________________
> > >
> > > Deze e-mail, inclusief eventuele bijlagen, is uitsluitend bestemd voor
> > > (gebruik door) de geadresseerde. De e-mail kan persoonlijke of
> > > vertrouwelijke informatie bevatten. Openbaarmaking, vermenigvuldiging,
> > > verspreiding en/of verstrekking van (de inhoud van) deze e-mail (en
> > > eventuele bijlagen) aan derden is uitdrukkelijk niet toegestaan.
> Indien u
> > > niet de bedoelde geadresseerde bent, wordt u vriendelijk verzocht
> degene
> > > die de e-mail verzond hiervan direct op de hoogte te brengen en de
> e-mail
> > > (en eventuele bijlagen) te vernietigen.
> > >
> > > Informatie vennootschap<http://www.ns.nl/emaildisclaimer>
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [hidden email]
> > > For additional commands, e-mail: [hidden email]
> > >
> > >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
> ________________________________
>
> Deze e-mail, inclusief eventuele bijlagen, is uitsluitend bestemd voor
> (gebruik door) de geadresseerde. De e-mail kan persoonlijke of
> vertrouwelijke informatie bevatten. Openbaarmaking, vermenigvuldiging,
> verspreiding en/of verstrekking van (de inhoud van) deze e-mail (en
> eventuele bijlagen) aan derden is uitdrukkelijk niet toegestaan. Indien u
> niet de bedoelde geadresseerde bent, wordt u vriendelijk verzocht degene
> die de e-mail verzond hiervan direct op de hoogte te brengen en de e-mail
> (en eventuele bijlagen) te vernietigen.
>
> Informatie vennootschap<http://www.ns.nl/emaildisclaimer>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Edge router on the client side

Chuck Rolke


----- Original Message -----

> From: "Ganesh Murthy" <[hidden email]>
> To: [hidden email]
> Sent: Monday, November 23, 2020 9:22:02 AM
> Subject: Re: Edge router on the client side
>
> On Mon, Nov 23, 2020 at 7:37 AM Petrenko, Vadim <[hidden email]>
> wrote:
>
> > Thank you guys for your responses.
> >
> > What bothers me is that such an Edge router placed at the client will have
> > all the topology information about every single other router in the
> > network, how they are interconnected, etc., as it has to participate in the
> > routing data exchange. It will even expose the Qpid console! Will show
> > network throughput, etc. Some data a client should have no access to imo.
> >
>
> > Some of these clients in our case might have intermittent connections over
> > weak links, and there could be quite a few of them (i.e. several thousands
> > clients). So this routing information would have to be exchanged every time
> > a client's Edge router connects to the core network.
> >
> When the edge router connects to a router network (to an interior router),
> the router network thinks of the edge router as just just another client
> albeit a "special" client. The edge router itself is not part of the
> network. Whenever a qdstat client asks the edge router for the topology of
> the router network, it in turn asks the interior it is connected to for
> that information. That being said, I wonder if you can use some policy
> restrictions on the interior router to block all management requests
> (requests to $management address) coming from the edge router (I would let
> the policy experts weigh in on this). This would effectively block the edge
> router from accessing any sensitive information about the router network
> but still allowing qdstat/qdmanage  to work within the context of the edge
> router.

Using policy to restrict what address to which a client is allowed to read
or to write is most definitely an option. See
https://qpid.apache.org/releases/qpid-dispatch-1.14.0/user-guide/index.html#vhost-policy-examples-qdr

Policy can also restrict the number of connections a user may have simultaneously,
maximum message size, and other resource limits.
https://qpid.apache.org/releases/qpid-dispatch-1.14.0/user-guide/index.html#configuring-authorization-qdr


>
> >
> > Do you have any ideas how to mitigate this or maybe this shouldn't
> > actually deserve any serious concerns?
> >
> > Thank you.
> >
> > -----Original Message-----
> > From: Chuck Rolke <[hidden email]>
> > Sent: vrijdag 20 november 2020 17:57
> > To: [hidden email]
> > Subject: Re: Edge router on the client side
> >
> > Also, do not build the image with certificates embedded within it.
> > Find a way to inject the connection secrets into the container as it is
> > launched.
> >
> >
> > ----- Original Message -----
> > > From: "Ted Ross" <[hidden email]>
> > > To: [hidden email]
> > > Sent: Friday, November 20, 2020 10:53:45 AM
> > > Subject: Re: Edge router on the client side
> > >
> > > On Fri, Nov 20, 2020 at 5:32 AM Petrenko, Vadim <[hidden email]>
> > > wrote:
> > >
> > > > Hi Qpid developers,
> > > >
> > > > We’re considering this possibility:
> > > >
> > > > Containerize a preconfigured Edge router (possibly together with
> > Artemis)
> > > > and give it to an application team.
> > > >
> > > > The application team will then deploy this container in their
> > environment
> > > > -> the Edge router will connect to a couple Interior routers in our
> > Core
> > > > network -> the client application will connect to the Edge router in
> > the
> > > > container using standard libraries like Qpid-JMS.
> > > >
> > > > We expect this to allow easy scaling up of clients. We also want to
> > attach
> > > > a broker to the edge router in case messages need to be buffered (but
> > this
> > > > is client specific and does not belong to the generic core network
> > setup).
> > > >
> > > > Does this setup look reasonable from a Qpid developer’s point of view?
> > > > Maybe there are some pitfalls to watch out for? Especially exposing
> > > > Interior routers to the world.
> > > >
> > >
> > > This is a good use case, and one that I think is appropriate for edge
> > > routers.
> > >
> > > If you are going to deploy your interior routers in a public place, I
> > think
> > > you would want strong security (mutual TLS) on those open ports.  Can you
> > > issue certificates to your application teams in the form of secrets so
> > they
> > > can securely connect to your network?
> > >
> > >
> > > >
> > > >
> > > > Thanks!
> > > >
> > > >
> > > >
> > > > ________________________________
> > > >
> > > > Deze e-mail, inclusief eventuele bijlagen, is uitsluitend bestemd voor
> > > > (gebruik door) de geadresseerde. De e-mail kan persoonlijke of
> > > > vertrouwelijke informatie bevatten. Openbaarmaking, vermenigvuldiging,
> > > > verspreiding en/of verstrekking van (de inhoud van) deze e-mail (en
> > > > eventuele bijlagen) aan derden is uitdrukkelijk niet toegestaan.
> > Indien u
> > > > niet de bedoelde geadresseerde bent, wordt u vriendelijk verzocht
> > degene
> > > > die de e-mail verzond hiervan direct op de hoogte te brengen en de
> > e-mail
> > > > (en eventuele bijlagen) te vernietigen.
> > > >
> > > > Informatie vennootschap<http://www.ns.nl/emaildisclaimer>
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: [hidden email]
> > > > For additional commands, e-mail: [hidden email]
> > > >
> > > >
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
> > ________________________________
> >
> > Deze e-mail, inclusief eventuele bijlagen, is uitsluitend bestemd voor
> > (gebruik door) de geadresseerde. De e-mail kan persoonlijke of
> > vertrouwelijke informatie bevatten. Openbaarmaking, vermenigvuldiging,
> > verspreiding en/of verstrekking van (de inhoud van) deze e-mail (en
> > eventuele bijlagen) aan derden is uitdrukkelijk niet toegestaan. Indien u
> > niet de bedoelde geadresseerde bent, wordt u vriendelijk verzocht degene
> > die de e-mail verzond hiervan direct op de hoogte te brengen en de e-mail
> > (en eventuele bijlagen) te vernietigen.
> >
> > Informatie vennootschap<http://www.ns.nl/emaildisclaimer>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]