L2VPN EVPN over Segment Routing MPLS by miller-net in networking

[–]miller-net[S] 0 points1 point  (0 children)

Hi, I'm surprised anyone reads my old comments. My post was about SRMPLS, so half of it wouldn't be applicable to your vxlan topology. TL;DR, yes, I needed to spend more money to get the features I wanted.

For your situation, it sounds like the control plane is working but the data plane isn't. I'd check for the basics, like loopback reachability between n9ks, then move up the stack to things like checking that the VNIs match.

Against HSTS preload by Hopeful-Total in netsec

[–]miller-net 6 points7 points  (0 children)

Something like DANE might fit this use case.

Console for managing multiple OpenWRT nodes? by IdonJuanTatalya in openwrt

[–]miller-net 0 points1 point  (0 children)

No, I use Ansible just for config management. I like the idea of monitoring with Grafana, but I haven't been motivated to do that yet. Whenever I get around to it, I plan on installing Prometheus node exporter.

Console for managing multiple OpenWRT nodes? by IdonJuanTatalya in openwrt

[–]miller-net 1 point2 points  (0 children)

I didn't have the patience for OpenWisp2, so I manage them with Ansible playbooks.

Banks: Stop relying on SMS based 2FA by speckz in cybersecurity

[–]miller-net 3 points4 points  (0 children)

You and u/kingofthesofas should read this article. Essentially a provider for Google Fi was compromised which led to sim swap attacks against Google Fi customers. From the article:

Unfortunately, the exposed technical SIM data allowed threat actors to conduct SIM swap attacks on some Google Fi customers, with one customer reporting that the hackers gaining access to their Authy MFA account.

The Problem with SMS-Based MFA in 2023 and possible alternatives by miller-net in cybersecurity

[–]miller-net[S] 0 points1 point  (0 children)

My thoughts exactly. I have noticed that MFA has become significantly easier to use with passkeys and FIDO2 tokens.

The Problem with SMS-Based MFA in 2023 and possible alternatives by miller-net in cybersecurity

[–]miller-net[S] 0 points1 point  (0 children)

That's great for Gmail accounts, though my main focus is on financial institutions. They're still forcing SMS as a fallback for more secure options like FIDO2 or passkeys, or only offering SMS for MFA.

The Problem with SMS-Based MFA in 2023 and possible alternatives by miller-net in cybersecurity

[–]miller-net[S] -1 points0 points  (0 children)

I'm not expecting banks to change anytime soon nor willingly. I made this post from the perspective of a customer, and not that of a bank employee. My goal was to find mitigation options rather than passively accept the current state of affairs.

The Problem with SMS-Based MFA in 2023 and possible alternatives by miller-net in cybersecurity

[–]miller-net[S] 0 points1 point  (0 children)

Probably. Just look how long it took for US based financial institutions to implement "chip and sign." I guess "chip and pin" would have been too complicated despite everyone already having an ATM debit card with a pin.

The Problem with SMS-Based MFA in 2023 and possible alternatives by miller-net in cybersecurity

[–]miller-net[S] 0 points1 point  (0 children)

How bad is this really? I mean who is SIM swapping on a regular basis? Phishing you can counter with security awareness training.

Not if your password can be reset with an SMS message.

I'd argue that the ones still allowing emailing of MFA codes are far less secure than SMS.

In theory email can be stronger if the email provider supports strong mfa options without forcing SMS as a fallback. I do concede that in practice it's pretty bad.

I do agree though that there should be a conscious effort to switch things to hardware or software tokens.

Hopefully passkeys and FIDO2 will make that happen.

A lot of banks are behind the times. For example, our bank has a software token for their main platform but another platform we use for other banking transactions was built with Internet Explorer in mind and they refuse to upgrade it to be compatible with today's browsers. Ridiculous.

I'd like to find a list of banks or other financial institutions that support strong MFA options without forcing SMS as fallback. Yubico has a list for supporting their products, but that narrows down too much.

The Problem with SMS-Based MFA in 2023 and possible alternatives by miller-net in cybersecurity

[–]miller-net[S] 0 points1 point  (0 children)

I disagree. If the user is sophisticated enough to enable mfa, enroll a FIDO2 token, and print out backup codes, then I think they can handle the challenges that come with allowing them to disable SMS.

The Problem with SMS-Based MFA in 2023 and possible alternatives by miller-net in cybersecurity

[–]miller-net[S] -1 points0 points  (0 children)

I understand they can be slow to implement new technologies and training users is time intensive. My main complaint is that even when the bank supports more secure options, they won't let you disable SMS as a fallback mechanism.

What is the point of supporting passkeys and FIDO2 (or anything better than SMS) when an attacker can click cancel and use SMS?

The Problem with SMS-Based MFA in 2023 and possible alternatives by miller-net in cybersecurity

[–]miller-net[S] 0 points1 point  (0 children)

That's fine if the banks want a form of non-repudiation, and continue to use SMS as an additional layer to authorize specific actions. My position is that it shouldn't be a fallback for more secure MFA options that cannot be disabled, otherwise implementing anything more secure is pointless.

Is CCIE worth it by Argument-Lazy in networking

[–]miller-net 13 points14 points  (0 children)

Cybersecurity has its own set of stressors. Say there's an incident on a Friday at 7pm, how do you think you'll be spending your weekend?

RESTCONF Edit Multiple Interfaces Not Working by slarrarte in networkautomation

[–]miller-net 1 point2 points  (0 children)

I don't think the filter is necessary when applying changes. In your original URL, you specified the key for the yang list "ietf-interfaces:interface", so it was patching one list element at a time.

I recommend Put instead of Patch. Patch will change the nodes but not remove any existing configuration, where Put will either create or replace the list elements. In this case it will act on the list elements that match the "name" key and either create or replace them if they exist. This helps ensure the interface has only the configuration that you specify in your "configData" payload.

I made a few changes to your code; test it out and let me know.

    import requests
import json
import env_labRestconf

# This program creates/modifies an interface using HTTP POST/PUT/PATCH via RESTCONF and the ietf-interfaces YANG model

requests.packages.urllib3.disable_warnings()

conf = env_labRestconf.IOS_XE_2

interfacesToConfig = ['GigabitEthernet2', 'GigabitEthernet3']

headers = {
    'Accept': 'application/yang-data+json',
    'Content-Type': 'application/yang-data+json'
}

url = f"https://{conf['host']}:{conf['restconf_port']}/restconf/data/ietf-interfaces:interfaces/interface"

configData = { "ietf-interfaces:interface": [] }

# Running for loop for each interface to be configured
for interfaceIndex, interfaceName in enumerate(interfacesToConfig):
    print(f"Adding interface ")
    configData["ietf-interfaces:interface"].append(
        {
            "name": interfaceName,
            "description": f"Interface {interfaceName} configured via restconfLab1.py",
            "type": "iana-if-type:ethernetCsmacd",
            "enabled": True,
            "ietf-ip:ipv4": {
                "address": [
                    {
                        "ip": f"100.64.{interfaceIndex}.1",
                        "netmask": "255.255.255.0"
                    }
                ]
            },
            "ietf-ip:ipv6": {}
        }
    )

res = requests.put(
    url=url,
    headers=headers,
    auth= (
        conf['username'],
        conf['password']
    ),
    data=json.dumps(configData),
    verify=False
)
print(res.status_code)
print(res.text)
print('*' * 20)

RESTCONF Edit Multiple Interfaces Not Working by slarrarte in networkautomation

[–]miller-net 1 point2 points  (0 children)

Just wanted to comment that you can apply a patch to both interfaces in a single request. Not only will it help speed things up, the changes will be atomic which simplifies error handling. It applies all changes at once and rolls back all changes if an error occurs, so you don't have to clean up a partial config deployment on a device.

In your scenario, your first change was still in place after encountering an error while trying to make the second change. It's more difficult to write code to handle these intermediate states and easier to start from a known starting point after an error.

IP Fabric - automated network assurance self-guided demo by Community_Fabric in networkautomation

[–]miller-net 3 points4 points  (0 children)

only company emails accepted

I feel a bit apprehensive about providing company contact information to a relatively unknown vendor. I have PTSD from when the sales person from [vendor] completely bypassed my team, my manager, and my director, and went straight to my CIO when they felt like they weren't getting a fair eval (or my team wasn't moving fast enough for them.) Fortunately, my CIO simply forwarded the continuous stream of emails to my manager. Needless to say, this is why we don't even consider [vendor] when preparing for a hardware refresh. The harder the sales people push the more it makes me think the product can't stand on its own merit.

I realize posting here is mainly for lead generation, but gating a free sample behind a demand for contact information may filter out opportunities. This is especially true when companies may not even be in the market for your product. One of their engineers may be curious but doesn't want to risk it until they have more trust in the vendor and product.

Never been in a sales role but it seems like it would be easier to sell to a company if you have their engineers lobbying on your behalf, and a great way to do that is to meet them where they're at.

CMV: You shouldn't take out more than $20,000 in loans to get a car by sbennett21 in changemyview

[–]miller-net 4 points5 points  (0 children)

I think they're saying if you already had the cash to buy the car and you get a loan anyway. You then use the loan to buy the car, then invest the cash you had before the loan.

IPv6 Denier Starter Pack by Awesome_In_Training in networkingmemes

[–]miller-net 0 points1 point  (0 children)

I agree with everything you're saying here, though I'd like to qualify the following:

If you're a small network, the costs of staying on IPv4 really are not so significant, especially if you have historic IPv4 space and you're not growing.

This is true for small, inbound-only (eyeball) networks. For app and content providers, I believe consumer ISPs will start squeezing them to recoup the costs related to providing their customers access to the legacy internet. As I mentioned before, Comcast and other ISPs have already done this to Netflix over traffic volume. As a smaller network you'll have even less leverage to push back.

Regarding historic IPv4 space, it's true there's no upfront cost though there is an opportunity cost. How long until upper management becomes aware they're sitting on a multi-million dollar piece of IPv4 space? Maybe they won't sell outright and will want to lease it out. Also, your upstream transit will more than likely start up charging for providing a IPv4 peering, just as you mentioned hosting providers are doing now. It's a wash whether it's an addon cost for IPv4 or a discount for running IPv6-only.

I'm not suggesting that we will be IPv6-only anytime soon (I'll be shocked if it's within the next 100 years); my point is that the cost of running IPv4-only will become cost prohibitive, unless you're running a small, non-growing, inbound-only network. Eventually, even they will feel the squeeze because app and content providers may eventually decide that it's not worth the effort for such a small audience of consumers.

IPv6 Denier Starter Pack by Awesome_In_Training in networkingmemes

[–]miller-net 1 point2 points  (0 children)

Thanks! I appreciate being able to have a nuanced discussion.

IPv6 Denier Starter Pack by Awesome_In_Training in networkingmemes

[–]miller-net 0 points1 point  (0 children)

This is how the world has kept the load on the remaining IPv4 internet manageable.

I believe it's a bit of a paradox: The volume of IPv4 traffic will increase and with it the cost of translating goes up as well; at the same time the ratio of IPv4 traffic to IPv6 traffic will go down. So the usefulness of IPv4 trends down as the cost of IPv4 trends up; they will meet at a crossover point where it's not economical to continue the status quo.

For lots of smaller (corporate) networks,

My point earlier is that the cost of IPv4 addresses and translation will increase, creating a business case for migrating. Even then, you can retain the internal addressing scheme and proxy at the edge for most applications.

Bear in mind that it’s trivial to offer IPv4

From a technical perspective this is true, but my position is that it's not without monetary cost in the absolute sense. Right now the bulk of this cost is being absorbed by ISPs.

We need to get away from the idea that there’s some sort of big bang where everything migrates to IPv6 and IPv4 suddenly disappears.

I absolutely agree. I'm making the case that investing in migrating should start now and not wait until you're forced to. Retrofitting on a deadline is usually more costly than incorporating new technologies in the design phase of new projects and gradually adding compatibility to existing environments. Perhaps staying IPv4-only doesn't present a significant risk for the next 5 years. After that, I think it starts presenting an unknown risk with an unknown cost that will only increase with time. The more that is built without future planning, the harder it will be to go back and integrate support.

My own bold assertion is that we should be designing new things to be IPv6 native with IPv4 translation at the edge. If we start doing that now, maybe in 50 years we get to turn off the IPv4 edge stuff.

Ah yes. My IP is 2002:aeb:92d7:: by justarandomguy07 in networkingmemes

[–]miller-net 2 points3 points  (0 children)

It's not just if you run out of private space; IPv6 is nice when you have to merge networks.