Re: [j-nsp] About Secure Transport for RPKI on JUNOS
Hello, Gert. On Thu, Dec 27, 2018 at 2:28 AM Gert Doering wrote: > Hi, > > On Wed, Dec 26, 2018 at 09:40:57PM +0800, Pyxis LX wrote: > > I'm not sure I agree with your opinion about SSH. > > IMHO if a KEX/MAC/Cipher algorithm that is generally considered insecure > by > > the security community, it might not be a good idea to keep using it:) > > This very much depends on what your focus is. Mine is more "operational > stability" - and if unattended machine-to-machine communication breaks, > causing operational outage, because one side decides to upgrade their > SSH implementation and existing algorithms stop working, then I know what > my answer will be. > > Like, when Fortinet upgraded their SSH backend in one of the minor > releases, > not even mentioning it in the release notes and all of a sudden SSH-DSA > keys stopped working. While the CLI still happily let us enter DSA keys, > they just did not work anymore, with no hint whatsoever anywhere. Broke > quite a bit of our automatization system which was still using DSA keys > because *other* vendors couldn't be bothered to implement RSA keys in a > timely fashion... > > I can see your point here. We keep at least 2 sets of NMS modules to deal with this kind of problem. Security is a serious concern when doing inband management. Probably more important than operational stability as you can almost always find a workaround manually. And I have the same feeling that most vendors lacks comprehensive configuration knobs on SSH subsystem. This should be enhanced. (HostKey management, TrustedUserCAKeys...etc for example) BTW, I'll consider the Fortinet CLI inconsistency as a software bug that shall be fixed. > > And please don't get me wrong, TCP-AO is totally fine with rpki-rtr since > > it provides integrity. > > Integrity provided by either SSHv2 tunnel or TLS, TCP-AO, ...etc. is > > mandatory when using external rpki-rtr servers or renting a pseudo leased > > line from other carriers that you might not have 100% trust. > > Sure. > gert > > -- > "If was one thing all people took for granted, was conviction that if you > feed honest figures into a computer, honest figures come out. Never > doubted > it myself till I met a computer with a sense of humor." > Robert A. Heinlein, The Moon is a Harsh > Mistress > > Gert Doering - Munich, Germany > g...@greenie.muc.de > ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX4650 or QFX5120 Use Case
I have (9) qfx5120-48y-8c
{master:0}
root> show system information
Model: qfx5120-48y-8c
Family: junos-qfx
Junos: 18.3R1.11
I plan to deploy them fairly simply at this point
I plan to have (4) in each of my (2) DC's
DC1
(2) QFX5120's for Services vlans/evpns
(2) QFX5120's for SAN/iscsi type vlans/evpns
DC2
(2) QFX5120's for Services vlans/evpns
(2) QFX5120's for SAN/iscsi type vlans/evpns
Lab Spare
(1) QFX5120 for testing
...so that's the (9) QFX5120's...
...so pretty much each QFX5120 I plan to uplink like this...
(1) QFX5120 dual connected 40 gig lacp (80 gig ae) to (2) separate
MPC7E-MRATE linecards in (1) MX960,
...so there won't be 960 redundancy, but there will be power zone and
linecard redundancy
*** To be clear, I intend on the EVPN logic/config be on the MX960 only, and
not on the QFX5120 at this point
*** I intend on the QFX5120 to be an Ethernet switch with lots of 10/25 gig
interfaces, and dual 40 gig uplinks
*** I don't intend on mpls fordarding nor routing to occur in the QFX5120
*** I don't intend on VC'ing the (2) QFX5120's sitting side by side
...could this change?...perhaps, but this is where I'm at, at this point
The servers and vm's in the DC will dual connect (2) 25 gig to different
QFX5120's
If the MX960 is spine...
If the QFX5120 is leaf...
...I've seen/read/heard that you typically don't interconnect the leafs...
so I don't intend on interconnecting the leafs (QFX5120) together, but
rather bridge via the MX960 BUT, I'm going to test an interconnect
east/west between (2) QFX5120's at a DC to see if I like it or in case we
have a necessity, I'll be ready... also, I'd imaging the active/active
m-home'd CE-to-PE EVPN as predicated on the dual CE (in this case dual qfx)
being interconnected, so I'll give it a whirl...
My EVE-NG lab has this pretty much already built out... examples of vMX and
vQFX are shown below... I think the newest vQFX junos is 18.1 so it's as
close as I could get to 18.3 which shipped on my qfx's
{master:0}
root@sabn-qfx-01> show system information
Model: vqfx-1
Family: junos-qfx
Junos: 18.1R1.9
Hostname: sabn-qfx-01
root@sabn-960> show system information
Model: vmx
Family: junos
Junos: 18.2R1.9
Hostname: sabn-960
I will have more to share as I deploy/test/turn-up after the new year...
- Aaron
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] About Secure Transport for RPKI on JUNOS
On Wed, 26 Dec 2018 14:11:19 -0500, sth...@nethelp.no wrote: > > Now if Juniper could implement TCP-AO and then donate the implementation > to FreeBSD? :-) This was sort of my point, yes. Thanks, as always for your cogent point(s). -chris (without something to break the ao logjam we'll just keep on having this argument, maybe we can isntead paste-bin this thread and just refer all other callers there? :) ) ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] EX4650 or QFX5120 Use Case
Hello, Does anyone uses EX4650 or QFX5120 (new products) with JUNOS 18.3 or 18.4 ? Any update for share about the product itself, features (MPLS, EVPN ... ), junos code, scaling, etc ? What kind of use cases are you using this new products ? Is it possible to share any experience ? Thanks a lot, Giuliano WZTECH is registered trademark of WZTECH NETWORKS. Copyright © 2018 WZTECH NETWORKS. All Rights Reserved. IMPORTANTE: As informações deste e-mail e o conteúdo dos eventuais documentos anexos são confidenciais e para conhecimento exclusivo do destinatário. Se o leitor desta mensagem não for o seu destinatário, fica desde já notificado de que não poderá divulgar, distribuir ou, sob qualquer forma, dar conhecimento a terceiros das informações e do conteúdo dos documentos anexos. Neste caso, favor comunicar imediatamente o remetente, respondendo este e-mail ou telefonando ao mesmo, e em seguida apague-o. CONFIDENTIALITY NOTICE: The information transmitted in this email message and any attachments are solely for the intended recipient and may contain confidential or privileged information. If you are not the intended recipient, any review, transmission, dissemination or other use of this information is prohibited. If you have received this communication in error, please notify the sender immediately and delete the material from any computer, including any copies. WZTECH is registered trademark of WZTECH NETWORKS. Copyright © 2018 WZTECH NETWORKS. All Rights Reserved. IMPORTANTE: As informações deste e-mail e o conteúdo dos eventuais documentos anexos são confidenciais e para conhecimento exclusivo do destinatário. Se o leitor desta mensagem não for o seu destinatário, fica desde já notificado de que não poderá divulgar, distribuir ou, sob qualquer forma, dar conhecimento a terceiros das informações e do conteúdo dos documentos anexos. Neste caso, favor comunicar imediatamente o remetente, respondendo este e-mail ou telefonando ao mesmo, e em seguida apague-o. CONFIDENTIALITY NOTICE: The information transmitted in this email message and any attachments are solely for the intended recipient and may contain confidential or privileged information. If you are not the intended recipient, any review, transmission, dissemination or other use of this information is prohibited. If you have received this communication in error, please notify the sender immediately and delete the material from any computer, including any copies. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] About Secure Transport for RPKI on JUNOS
On Wed, 26 Dec 2018 13:36:49 -0500, Bjørn Mork wrote: > > Chris Morrow writes: > > On Sun, 23 Dec 2018 16:15:24 -0500, > > Melchior Aelmans wrote: > >> > >> Hi Pyxis, > >> > >> On Sat, Dec 22, 2018 at 8:58 AM Pyxis LX wrote: > >> > >> > Does JUNOS support any secure transports mentioned in RFC6810 for > >> > rpki-rtr > >> > protocol? (SSHv2/IPsec or TLS for rpki-rtr-tls?) > >> > > >> > >> We are discussing internally what secure transport method to support. I'm > >> happy to hear your ideas. > > > > 'tcp-ao' - yes... srsly. > > Huh? Why? No support on any server OS, AFAIK. Yes, there were patches > for FreeBSD and Linux a few years ago, but I don't think they went > anywhere? This will severely limit the usability. there's no support elsewhere because no one that cares (you, me, network people) can get vendors to deploy AO. There's no support in network devices because there's no support in linux/etc ... this is a pretty horrid place to be :( so, if folk want to put AO into junos for this, we can get it for the other vendors and for other parts of each vendor's problem-space... and along the way we'll get it for linux/*bsd (I expect). > Let's have ssh, and optionally tls. We need something we can run on a > server today. Not 8 year old foilware. ssh isn't in the right form on pretty much any vendor's device, so said the vendor implementers many times during rpki-rtr development/process. (hannes gredler, jeff haas, several cisco folks as well). tls brings with it cert issues. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] About Secure Transport for RPKI on JUNOS
> On Dec 26, 2018, at 2:11 PM, sth...@nethelp.no wrote: > We are discussing internally what secure transport method to support. I'm happy to hear your ideas. >>> >>> 'tcp-ao' - yes... srsly. >> >> Huh? Why? No support on any server OS, AFAIK. Yes, there were patches >> for FreeBSD and Linux a few years ago, but I don't think they went >> anywhere? This will severely limit the usability. >> >> Let's have ssh, and optionally tls. We need something we can run on a >> server today. Not 8 year old foilware. > > Now if Juniper could implement TCP-AO and then donate the implementation > to FreeBSD? :-) A few of us could do the TCP-AO work in Linux/*BSD but I know which kernel team will reject it as “not implemented by core team” based on my experience. - Jared ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] About Secure Transport for RPKI on JUNOS
> On Dec 26, 2018, at 1:36 PM, Bjørn Mork wrote: > > Chris Morrow writes: >> On Sun, 23 Dec 2018 16:15:24 -0500, >> Melchior Aelmans wrote: >>> >>> Hi Pyxis, >>> >>> On Sat, Dec 22, 2018 at 8:58 AM Pyxis LX wrote: >>> Does JUNOS support any secure transports mentioned in RFC6810 for rpki-rtr protocol? (SSHv2/IPsec or TLS for rpki-rtr-tls?) >>> >>> We are discussing internally what secure transport method to support. I'm >>> happy to hear your ideas. >> >> 'tcp-ao' - yes... srsly. > > Huh? Why? No support on any server OS, AFAIK. Yes, there were patches > for FreeBSD and Linux a few years ago, but I don't think they went > anywhere? This will severely limit the usability. > > Let's have ssh, and optionally tls. We need something we can run on a > server today. Not 8 year old foilware. *Insert anti-FreeBSD snark about how problematic it is, as it burned me in production once too many times .. yes a RC is there to tell you when you broke the network driver built into the motherboard and yes you should fix it before posting -RELEASE but we don’t care about the end-users so .. yeah I hate it* TCP-AO, regardless of the OS is going to be much easier to use compared to ssh or TLS. SSH and TLS come with extra complexity as I mentioned before. TCP-AO please. It would be nice to see many packages updated.. OpenSSH could use an update from 7.2 and the NTP daemon as well from 4.2.0-a to something much newer as well. If you’ve not been following the IETF activities btw, md5 does cause some head scratching when a protocol gets a security review. It’s amusing to watch when you say “I need something more stable than TLS provides the capability for”, or “I care about integrity not confidentiality” and the crypto zealots heads explode.. - Jared ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] About Secure Transport for RPKI on JUNOS
>>> We are discussing internally what secure transport method to support. I'm >>> happy to hear your ideas. >> >> 'tcp-ao' - yes... srsly. > > Huh? Why? No support on any server OS, AFAIK. Yes, there were patches > for FreeBSD and Linux a few years ago, but I don't think they went > anywhere? This will severely limit the usability. > > Let's have ssh, and optionally tls. We need something we can run on a > server today. Not 8 year old foilware. Now if Juniper could implement TCP-AO and then donate the implementation to FreeBSD? :-) Steinar Haug, Nethelp consulting, sth...@nethelp.no ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] About Secure Transport for RPKI on JUNOS
If we are talking about SSH in Junos I am waiting for TrustedUserCAKeys support as describe in https://code.fb.com/security/scalable-and-secure-access-with-ssh/ Nitzan On Wed, Dec 26, 2018 at 8:39 PM Bjørn Mork wrote: > Chris Morrow writes: > > On Sun, 23 Dec 2018 16:15:24 -0500, > > Melchior Aelmans wrote: > >> > >> Hi Pyxis, > >> > >> On Sat, Dec 22, 2018 at 8:58 AM Pyxis LX wrote: > >> > >> > Does JUNOS support any secure transports mentioned in RFC6810 for > rpki-rtr > >> > protocol? (SSHv2/IPsec or TLS for rpki-rtr-tls?) > >> > > >> > >> We are discussing internally what secure transport method to support. > I'm > >> happy to hear your ideas. > > > > 'tcp-ao' - yes... srsly. > > Huh? Why? No support on any server OS, AFAIK. Yes, there were patches > for FreeBSD and Linux a few years ago, but I don't think they went > anywhere? This will severely limit the usability. > > Let's have ssh, and optionally tls. We need something we can run on a > server today. Not 8 year old foilware. > > > > Bjørn > ___ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp > ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] About Secure Transport for RPKI on JUNOS
Chris Morrow writes: > On Sun, 23 Dec 2018 16:15:24 -0500, > Melchior Aelmans wrote: >> >> Hi Pyxis, >> >> On Sat, Dec 22, 2018 at 8:58 AM Pyxis LX wrote: >> >> > Does JUNOS support any secure transports mentioned in RFC6810 for rpki-rtr >> > protocol? (SSHv2/IPsec or TLS for rpki-rtr-tls?) >> > >> >> We are discussing internally what secure transport method to support. I'm >> happy to hear your ideas. > > 'tcp-ao' - yes... srsly. Huh? Why? No support on any server OS, AFAIK. Yes, there were patches for FreeBSD and Linux a few years ago, but I don't think they went anywhere? This will severely limit the usability. Let's have ssh, and optionally tls. We need something we can run on a server today. Not 8 year old foilware. Bjørn ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] About Secure Transport for RPKI on JUNOS
Hi, On Wed, Dec 26, 2018 at 09:40:57PM +0800, Pyxis LX wrote: > I'm not sure I agree with your opinion about SSH. > IMHO if a KEX/MAC/Cipher algorithm that is generally considered insecure by > the security community, it might not be a good idea to keep using it:) This very much depends on what your focus is. Mine is more "operational stability" - and if unattended machine-to-machine communication breaks, causing operational outage, because one side decides to upgrade their SSH implementation and existing algorithms stop working, then I know what my answer will be. Like, when Fortinet upgraded their SSH backend in one of the minor releases, not even mentioning it in the release notes and all of a sudden SSH-DSA keys stopped working. While the CLI still happily let us enter DSA keys, they just did not work anymore, with no hint whatsoever anywhere. Broke quite a bit of our automatization system which was still using DSA keys because *other* vendors couldn't be bothered to implement RSA keys in a timely fashion... > And please don't get me wrong, TCP-AO is totally fine with rpki-rtr since > it provides integrity. > Integrity provided by either SSHv2 tunnel or TLS, TCP-AO, ...etc. is > mandatory when using external rpki-rtr servers or renting a pseudo leased > line from other carriers that you might not have 100% trust. Sure. gert -- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress Gert Doering - Munich, Germany g...@greenie.muc.de signature.asc Description: PGP signature ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] About Secure Transport for RPKI on JUNOS
On Mon, 24 Dec 2018 02:38:35 -0500, Melchior Aelmans wrote: > > Hi Chris, > > > Op 24 dec. 2018 om 05:11 heeft Chris Morrow het > > volgende geschreven: > > > > On Sun, 23 Dec 2018 16:15:24 -0500, > > Melchior Aelmans wrote: > >> > >> Hi Pyxis, > >> > >>> On Sat, Dec 22, 2018 at 8:58 AM Pyxis LX wrote: > >>> > >>> Does JUNOS support any secure transports mentioned in RFC6810 for rpki-rtr > >>> protocol? (SSHv2/IPsec or TLS for rpki-rtr-tls?) > >>> > >> > >> We are discussing internally what secure transport method to support. I'm > >> happy to hear your ideas. > > > > 'tcp-ao' - yes... srsly. > > Im in favor but why do you think AO is the way to go? It seems SSH > and TLS have gained more support? Let me know your ideas. jared/gert covered most of this, but: I think things like TLS bring along with them certificate management issues. Some folk have infrastructure to deal with this, some do not. SSH is not, often, in the right form for devices to use as a library versus as 'spin up an ssh connection and tunnel over that' mode. there's the config management parts jared/gert pointed out as well. and finally... md5 is dead #sosayssecuritypeople so.. let's do something to move along AO? I'm not a huge AO fan, but it's 'the only thing left' in the 'make tcp secure again' space. thanks! -chris ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] About Secure Transport for RPKI on JUNOS
> On Dec 26, 2018, at 8:48 AM, Melchior Aelmans wrote: > > Personally I would say we need TCP-AO, not only for securing RTR but also to > replace MD5 in several protocols Yes, this would be a positive step. It will also take ~5-7 years for those on md5 to rotate to something else, but as I can’t configure it now on either Cisco/Juniper it’s a barrier to get to code that supports it, then a partner who can as well. - Jared ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] About Secure Transport for RPKI on JUNOS
> On Dec 25, 2018, at 5:22 AM, Job Snijders wrote: > > On Tue, Dec 25, 2018 at 09:08:32AM +0100, Gert Doering wrote: >> On Tue, Dec 25, 2018 at 02:46:57PM +0800, Pyxis LX wrote: >>> I think SSHv2 or IPSec with good CLI integration would be nice. >>> (ex: CLI to manage SSHv2 private keys, OSPFv3-like IPSec >>> integration...etc.) TLS might be good but as Jared said, certificate >>> revocation might not be that manageable. However it's better than >>> plain TCP anyway. >> >> Careful what you wish for. Adding heaps of crypto that all of a >> sudden decides "oh, this certificate is expired" or "bah, this >> algorithm is so insecure, we do not support this key exchange / mac / >> cipher anymore!" adds quite a bit of brittleness... >> >> So TCP-MD5 is actually nice because it has none of all that fanciness. > > Already today Junos ships with an OpenSSH client (and server). I'm not > too worried 'heaps of crypto' will be added if the SSH path is picked. > The problem is with key management systems. I’ve yet to see a router vendor do this well. If we had to go the SSL route, I would need to rotate keys, certs and integrate into the corporate CA properly. SSH transport is great until you have to update known_hosts on a thousand devices based on the nearest validator. - Jared ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] About Secure Transport for RPKI on JUNOS
Personally I would say we need TCP-AO, not only for securing RTR but also to replace MD5 in several protocols On Wed, Dec 26, 2018 at 2:43 PM Pyxis LX wrote: > Hi, Gert. > > I'm not sure I agree with your opinion about SSH. > IMHO if a KEX/MAC/Cipher algorithm that is generally considered insecure by > the security community, it might not be a good idea to keep using it:) > > And please don't get me wrong, TCP-AO is totally fine with rpki-rtr since > it provides integrity. > Integrity provided by either SSHv2 tunnel or TLS, TCP-AO, ...etc. is > mandatory when using external rpki-rtr servers or renting a pseudo leased > line from other carriers that you might not have 100% trust. > > Regards, > > Pyxis. > > > On Tue, Dec 25, 2018 at 4:08 PM Gert Doering wrote: > > > Hi, > > > > On Tue, Dec 25, 2018 at 02:46:57PM +0800, Pyxis LX wrote: > > > I think SSHv2 or IPSec with good CLI integration would be nice. > > > (ex: CLI to manage SSHv2 private keys, OSPFv3-like IPSec > > integration...etc.) > > > TLS might be good but as Jared said, certificate revocation might not > be > > > that manageable. > > > However it's better than plain TCP anyway. > > > > Careful what you wish for. Adding heaps of crypto that all of a sudden > > decides "oh, this certificate is expired" or "bah, this algorithm is so > > insecure, we do not support this key exchange / mac / cipher anymore!" > > adds quite a bit of brittleness... > > > > So TCP-MD5 is actually nice because it has none of all that fanciness. > > > > > After all, it's kind of ironic that we send the cryptographically > > verified > > > results without integrity. > > > > If someone can interfere with TCP packets *inside your network* without > > you noticing, RPKI-RTR is likely the least of your worries. > > > > (Using an externally hosted RPKI validator might change these arguments > > quite a bit) > > > > gert > > > > -- > > "If was one thing all people took for granted, was conviction that if you > > feed honest figures into a computer, honest figures come out. Never > > doubted > > it myself till I met a computer with a sense of humor." > > Robert A. Heinlein, The Moon is a Harsh > > Mistress > > > > Gert Doering - Munich, Germany > > g...@greenie.muc.de > > > ___ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp > ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] About Secure Transport for RPKI on JUNOS
Hi, Gert. I'm not sure I agree with your opinion about SSH. IMHO if a KEX/MAC/Cipher algorithm that is generally considered insecure by the security community, it might not be a good idea to keep using it:) And please don't get me wrong, TCP-AO is totally fine with rpki-rtr since it provides integrity. Integrity provided by either SSHv2 tunnel or TLS, TCP-AO, ...etc. is mandatory when using external rpki-rtr servers or renting a pseudo leased line from other carriers that you might not have 100% trust. Regards, Pyxis. On Tue, Dec 25, 2018 at 4:08 PM Gert Doering wrote: > Hi, > > On Tue, Dec 25, 2018 at 02:46:57PM +0800, Pyxis LX wrote: > > I think SSHv2 or IPSec with good CLI integration would be nice. > > (ex: CLI to manage SSHv2 private keys, OSPFv3-like IPSec > integration...etc.) > > TLS might be good but as Jared said, certificate revocation might not be > > that manageable. > > However it's better than plain TCP anyway. > > Careful what you wish for. Adding heaps of crypto that all of a sudden > decides "oh, this certificate is expired" or "bah, this algorithm is so > insecure, we do not support this key exchange / mac / cipher anymore!" > adds quite a bit of brittleness... > > So TCP-MD5 is actually nice because it has none of all that fanciness. > > > After all, it's kind of ironic that we send the cryptographically > verified > > results without integrity. > > If someone can interfere with TCP packets *inside your network* without > you noticing, RPKI-RTR is likely the least of your worries. > > (Using an externally hosted RPKI validator might change these arguments > quite a bit) > > gert > > -- > "If was one thing all people took for granted, was conviction that if you > feed honest figures into a computer, honest figures come out. Never > doubted > it myself till I met a computer with a sense of humor." > Robert A. Heinlein, The Moon is a Harsh > Mistress > > Gert Doering - Munich, Germany > g...@greenie.muc.de > ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
