Messages

https://thebulletin.org/2025/09/the-risks-in-the-protocol-connecting-ai-to-the-digital-world/#post-heading

model context protocol (MCP) is comin' to town, best get ready.

It runs on HTTP according to docs here: https://modelcontextprotocol.io/docs/getting-started/intro

So, I hope it can also run on HTTPS, but then there's the fun times about making sure all the encryption is done right and is made quantum-resistant when those ciphers are ready.

Communicates via JSON over HTTP.

I need to read the rest of the articles now... 

Congrats. Was it one of the ISC2 certs? Those are pretty well recognized.

-Otanx

This was a Qualys one. I'm next planning to do some AI Security courses with ISC2.

I picked up my first cloud security certification. Feels good.

Well, I signed on at ISC2 and I'm going to work on clearing the intro cert for cybersecurity and then going on to the cloud and AI certifications, whatever they got there. This is self-directed training on my own dime and time.

Internally, I'm going to work more on product training in Cloud / AI areas and getting up to speed in those venues. Traditional network stuff I got down very well, and finding out that AI security is basically an IPS/WAF for the AI inputs and outputs helps to put that security in context.

I recycled my old gear. Getting 50 bucks and postage wasn't worth lugging it around and trying to ram it into a box.

Well, time for me to do a deeper dive into CRCs...

In networking, the CRC is typically calculated on the fly as the data goes out of the network interface and is added to the end of the transmission. There is a SHA checksum with the data that is actually used to check for data integrity, so the CRC in networking is for the datalink to determine if there are any bit errors. CRC itself is too lightweight to do a proper integrity check, which is why the SHA checksum is included with the data set proper.

In environments with low to non existent error rates, CRC can be seen as redundant, especially with TCP data being sent with a SHA checksum on it. In operational technology (OT) environments, however, where the gear is thinly provisioned and data transmission is a priority, the CRC is used on the OT protocols as a quick and easy way to determine if the data arrived completely or if a retransmission is required.

For your case, the maths are by the sending system. Honestly, it does not matter what algorithm is used, so long as it's the one for the protocol being transmitted. Humans do not calculate CRC.

The data, 1010, will be manipulated until the system gets 0 and a remainder. The remainder are the CRC bits.

https://en.wikipedia.org/wiki/Cyclic_redundancy_check#Computation shows a sample calculation.

But in the real world, we don't look at the CRCs. We *will* look at CRC error rates on a device and, when they get too high, will consider corrective action on the hardware or connecting media.

To find the answer, I found this: https://en.wikipedia.org/wiki/Dijkstra%27s_algorithm

And it's a fun little article about how Dijkstra thought it all out and made the algorithm. There is a step-by-step calculation that runs until one of the calculated paths reaches the destination. That first path is therefore the shortest.

The algorithm also works, with modifications, to present ranked-choice alternatives to the shortest path, should it become unavailable or degraded.

Other shortest-path solutions are discussed here: https://en.wikipedia.org/wiki/Shortest_path_problem . Solutions don't necessarily fail, but are rather perhaps better for some applications than others.

Start with 92-100. If no ack, then retry those a third time.

It's the "sliding window" idea. If transmissions are good, send larger and larger chunks up to a limit. If there is an interruption, start small again and see if that gets through. If not, then there's no point in sending all the other stuff.

End to end means being able to track things in a system. In the case of TCP communications, it's confirmation messages. For UDP, as it does not have confirmation messages, then being able to detect breaks in the communication path will enable an administrator to determine if messages are being delivered or not.

NAT is a tricky thing, though. Used one time with the Internet connection, it is manageable. If it is used a second time for masking internal traffic, then problems develop. Problems multiply if address spaces are re-used in different areas and NAT is employed to mask the IP address re-use. This last scenario is common in industrial environments.

In the K3S cluster, how many nodes are being used? If the number is over 64K, then we may want to instead go with IPv6 instead of IPv4 with NAT.

That's a subject list that reads more like a history of the topic. For example, PGP was popular some time ago, but has since waned as major email providers have implemented encryption.

The biggest area to know is how public-key infrastructure (PKI) cryptography works, and how it is different from symmetric cryptography.

^indeed. But once the ACL has to be open for all the AD servers or something like that, it takes off and becomes something like 1800 lines for all the ports and IP addresses. This can lead to partial ACL application if things time out. Whereas "VLAN 911" - it's done in just the one line, less chance of a timeout issue.

Yes, and most Windows won't notice the change without an agent. This is why agentless solutions have to hard-bounce the port to get the device to request a new IP address. Any dot1x solution works so much better with agents that replace the Windows supplicant.

I have evil things to say about Windows supplicants, if you would like to hear them...

The more you do post-incident, the better your prep for the next one in terms of minimizing impact.

Ooof, no, I missed that news, I was taking some easy time, recovering from a cold.