Re: SRv6
> > Sounds like you're making a/the case for MACSec :-). > While I get your point, and it is a good one, no. Once lawyers, finance, and other functions get involved, it goes from being just another technology, to a pain for suppliers and customers alike. Export laws complicate implementation, and vendors can only afford and/or have the operational agility, to do an implementation once. Any security tech that is sufficiently interesting, is going to be a pain for router vendors to implement and operationalize given the government’s attitude to such tech. The lower in the stack it is, the bigger the pain. That said, vendors are being asked to put MACSec in and I suspect more platforms supporting it will become available over time.
Re: SRv6
> Information can be in plaintext and private Three can keep a secret, if two of them are dead. -- franklin i know you truely believe the tunnel k00laid. the security community does not. randy
Re: AS16509 Peering Contact
❦ 18 septembre 2020 21:03 +03, Paschal Masha: > Any Techie from AS16509 (Amazon) in here that can help with a peering > request for Denver and LA Any2 IXs that was sent to peering@amazon for days > now without a response :) It takes some time to get an answer from Amazon, but they eventually answer. Give them a few weeks. -- Avoid multiple exits from loops. - The Elements of Programming Style (Kernighan & Plauger)
AS16509 Peering Contact
Hello, Any Techie from AS16509 (Amazon) in here that can help with a peering request for Denver and LA Any2 IXs that was sent to peering@amazon for days now without a response :) *Paschal Masha* Lead Network Engineer 6x7 Networks | 1 (831)325-0544 Time Zone: PST
Weekly Routing Table Report
This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, SANOG, PacNOG, SAFNOG TZNOG, MENOG, BJNOG, SDNOG, CMNOG, LACNOG and the RIPE Routing WG. Daily listings are sent to bgp-st...@lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 19 Sep, 2020 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary BGP routing table entries examined: 823713 Prefixes after maximum aggregation (per Origin AS): 313888 Deaggregation factor: 2.62 Unique aggregates announced (without unneeded subnets): 396613 Total ASes present in the Internet Routing Table: 69426 Prefixes per ASN: 11.86 Origin-only ASes present in the Internet Routing Table: 59659 Origin ASes announcing only one prefix: 24758 Transit ASes present in the Internet Routing Table:9767 Transit-only ASes present in the Internet Routing Table:303 Average AS path length visible in the Internet Routing Table: 4.3 Max AS path length visible: 47 Max AS path prepend of ASN ( 37385) 44 Prefixes from unregistered ASNs in the Routing Table: 829 Number of instances of unregistered ASNs: 830 Number of 32-bit ASNs allocated by the RIRs: 33522 Number of 32-bit ASNs visible in the Routing Table: 27683 Prefixes from 32-bit ASNs in the Routing Table: 128618 Number of bogon 32-bit ASNs visible in the Routing Table:14 Special use prefixes present in the Routing Table:1 Prefixes being announced from unallocated address space:446 Number of addresses announced to Internet: 2860680832 Equivalent to 170 /8s, 130 /16s and 134 /24s Percentage of available address space announced: 77.3 Percentage of allocated address space announced: 77.3 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 99.5 Total number of prefixes smaller than registry allocations: 276420 APNIC Region Analysis Summary - Prefixes being announced by APNIC Region ASes: 216676 Total APNIC prefixes after maximum aggregation: 63566 APNIC Deaggregation factor:3.41 Prefixes being announced from the APNIC address blocks: 210515 Unique aggregates announced from the APNIC address blocks:86747 APNIC Region origin ASes present in the Internet Routing Table: 10861 APNIC Prefixes per ASN: 19.38 APNIC Region origin ASes announcing only one prefix: 3045 APNIC Region transit ASes present in the Internet Routing Table: 1590 Average APNIC Region AS path length visible:4.5 Max APNIC Region AS path length visible: 30 Number of APNIC region 32-bit ASNs visible in the Routing Table: 5963 Number of APNIC addresses announced to Internet: 779146752 Equivalent to 46 /8s, 112 /16s and 214 /24s APNIC AS Blocks4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 63488-64098, 64297-64395, 131072-141625 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8, 163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary Prefixes being announced by ARIN Region ASes:240915 Total ARIN prefixes after maximum aggregation: 111026 ARIN Deaggregation factor: 2.17 Prefixes being announced from the ARIN address blocks: 238608 Unique aggregates announced from the ARIN address blocks:116675 ARIN Region origin ASes present in the Internet Routing Table:18588 ARIN Prefixes per ASN:12.84 ARIN
Re: Hurricane AS6939 - Contact
Thanks Eric. I have been helped. I'm good now. *Paschal Masha* Lead Network Engineer 6x7 Networks | 1 (831)325-0544 Time Zone: PST On Fri, Sep 18, 2020 at 7:28 PM Eric Dugas wrote: > Their NOC is usually very responsive > > On Fri, Sep 18, 2020 at 10:46 AM Paschal Masha > wrote: > >> Hey, >> >> Any Techie from AS6939 to help with a routing issue in Denver ANY2 IX. >> Please contact me offlist. Thanks >> >> >> >> *Paschal Masha* >> Senior Network Engineer >> 6x7 Networks | 1 (831)325-0544 >> Time Zone: PST >> >
Re: Redhat contact
Hello You may contact distributors instead, such as Arrow or TechData. Best regards >> Le 18 sept. 2020 à 17:51, Eric Litvin a écrit : > > Hi, I need to get in contact with someone in the sales team at Redhat but > they are not replying either to my emails or phone calls. Do you know anyone > working for Redhat whom we can call? Please dm me. > > Thanks > > Eric Sent from my iPhone > >>> On Sep 18, 2020, at 7:48 AM, Wilco Baan Hofman wrote: >> >> >>> On 18/09/2020 12:07, Mark Tinka wrote: >>> >>> >>> There was a time when the use-case for MACSec was to move banks away >>> from running their own DWDM/FC networks, and letting operators do it. >> >> Well, the other use case is access networks with 802.1x. With 802.1x as >> long as the port stays up the session cookie (whatever is set as >> authenticated) is the MAC address. So once a port is authenticated, it's >> really easy to spoof a MAC and still be on the network. >> >> With WPA2 enterprise on WiFi, this problem does not exist, because then >> there is a cryptographic session. MACsec fixes that gap on wired. >> >> Not all that relevant for long-distance links though :) >> >> -- Wilco
Re: Hurricane AS6939 - Contact
Their NOC is usually very responsive On Fri, Sep 18, 2020 at 10:46 AM Paschal Masha wrote: > Hey, > > Any Techie from AS6939 to help with a routing issue in Denver ANY2 IX. > Please contact me offlist. Thanks > > > > *Paschal Masha* > Senior Network Engineer > 6x7 Networks | 1 (831)325-0544 > Time Zone: PST >
Redhat contact
Hi, I need to get in contact with someone in the sales team at Redhat but they are not replying either to my emails or phone calls. Do you know anyone working for Redhat whom we can call? Please dm me. Thanks Eric Sent from my iPhone > On Sep 18, 2020, at 7:48 AM, Wilco Baan Hofman wrote: > > > >> On 18/09/2020 12:07, Mark Tinka wrote: >> >> >> There was a time when the use-case for MACSec was to move banks away >> from running their own DWDM/FC networks, and letting operators do it. >> > > Well, the other use case is access networks with 802.1x. With 802.1x as > long as the port stays up the session cookie (whatever is set as > authenticated) is the MAC address. So once a port is authenticated, it's > really easy to spoof a MAC and still be on the network. > > With WPA2 enterprise on WiFi, this problem does not exist, because then > there is a cryptographic session. MACsec fixes that gap on wired. > > Not all that relevant for long-distance links though :) > > -- Wilco
Re: SRv6
On 18/09/2020 12:07, Mark Tinka wrote: > > There was a time when the use-case for MACSec was to move banks away > from running their own DWDM/FC networks, and letting operators do it. > Well, the other use case is access networks with 802.1x. With 802.1x as long as the port stays up the session cookie (whatever is set as authenticated) is the MAC address. So once a port is authenticated, it's really easy to spoof a MAC and still be on the network. With WPA2 enterprise on WiFi, this problem does not exist, because then there is a cryptographic session. MACsec fixes that gap on wired. Not all that relevant for long-distance links though :) -- Wilco
Hurricane AS6939 - Contact
Hey, Any Techie from AS6939 to help with a routing issue in Denver ANY2 IX. Please contact me offlist. Thanks *Paschal Masha* Senior Network Engineer 6x7 Networks | 1 (831)325-0544 Time Zone: PST
Re: SRv6
aar...@gvtc.com писал 2020-09-15 20:31: Hi Aaron, Also, with VPN's over SRv6 would this enable automatic vpn capability over the internet? I mean if I can do VPN's over an IPv6 network, seems that I could do that across the Internet as well. I think you already can do it over any kind of tunnel, and there are a lot of SDWAN solutions are available. Or do you expect from a transit provider a capability to respect and process SID stack programmed by another provider? I wouldn't bet on this ;) From administrative PoV it's similar to Inter-AS or CsC, based on trusted relations between parties, but seems not very popular in real life. Otherwise, it will be the same best path routing as for any general tunnel. Doesn't look as a distinctive advantage of SRv6 at least. - Aaron -- Kind regards, Andrey
Re: SRv6
On 16 September 2020 22:38:38 CEST, Randy Bush wrote: >> Privacy != encryption. > >cleartext == privacy * 0 > >cleartext * complexity == privacy * 0 False. Cleartext and privacy are two different things which are not mutually exclusive. Information can be in plaintext and private, it can also be encrypted and not private. Consider multiple devices connected to a single customer instance (A) on an MPLS L2 VPN provider's network, consisting of a single VLAN/broadcast domain, all the connected devices are able to send information to each other, and they can receive the information sent to other devices not intended for itself. Any device, for example, can send a gratuitous ARP, update the control plane of the switch and pull traffic towards itself and have visibility of all the conversation on the VLAN/broadcast domain. Even if the conversations are encrypted, meaning no plaintext, which you seem to suggest means privacy, this receiving device sees all the conversations which take place, when they are taking place, between whom, for how long, how often, and so on. Encryption hasn't provided privacy if someone can see all that information. Now consider a second customer (B) connected to a separate customer instance on the same L2 VPN provider network. Customer A can send any traffic they like and they can listen all day until the cows come home; they will never be able to send traffic to a customer B device in a separate L2 VPN instance, and they will never receive any traffic from a customer B device, they can't even see that customer B exists, if they are having any conversations, when, for how long etc, nothing. That is privacy, which is completely different to plaintext and ciphertext. Cheers, James
Re: SRv6
On 18/Sep/20 11:40, t...@pelican.org wrote: I've got MACSec deployed for exactly one customer as a point solution. It works once it's in, but the documentation, vendor or otherwise, and choice of suitable equipment were fairly sparse. I certainly wouldn't want to offer it at scale. Encrypted network conversations with customers, I always try to be very clear about what they're trying to protect against, and make them think properly about trust boundaries. Sure, I can slap a managed CPE on site if I don't already have one and provide overlay encryption - but that doesn't stop a rogue engineer on my side from capturing data before it's encrypted. If what you're concerned about is fibre taps, or security flaws in the MPLS traffic-segregation model or implementation, that helps. If you don't want to trust me as a service provider not to sniff your traffic in the middle, having me encrypt it at the edge really doesn't help - you need to encrypt it yourself, or have a different third-party that you do trust do the encryption. Some people get it, some people are just trying to fill auditor check-boxes ;) Agreed. There was a time when the use-case for MACSec was to move banks away from running their own DWDM/FC networks, and letting operators do it. I'm yet to find a bank willing to do this. Maybe I'm not paying enough attention. Mark.
Re: SRv6
> For me, MACSec is kind of like SyncE... great on paper and in the sales > pitch, but anyone that truly wants to use those features is probably > going to be architecting, deploying and managing them themselves, and > not paying a 3rd party network operator for the priviledge. I've got MACSec deployed for exactly one customer as a point solution. It works once it's in, but the documentation, vendor or otherwise, and choice of suitable equipment were fairly sparse. I certainly wouldn't want to offer it at scale. Encrypted network conversations with customers, I always try to be very clear about what they're trying to protect against, and make them think properly about trust boundaries. Sure, I can slap a managed CPE on site if I don't already have one and provide overlay encryption - but that doesn't stop a rogue engineer on my side from capturing data before it's encrypted. If what you're concerned about is fibre taps, or security flaws in the MPLS traffic-segregation model or implementation, that helps. If you don't want to trust me as a service provider not to sniff your traffic in the middle, having me encrypt it at the edge really doesn't help - you need to encrypt it yourself, or have a different third-party that you do trust do the encryption. Some people get it, some people are just trying to fill auditor check-boxes ;) Regards, Tim.
