The post Worth Reading: Stop Trying to Deter Cyber Criminals appeared first on 'net work.
The post Worth Reading: Building the LinkedIn Knowledge Graph appeared first on 'net work.
The post Worth Reading: Limitations of Current Branch Office WAN appeared first on 'net work.
The post Worth Reading: Data Centric Computing appeared first on 'net work.
The post Worth Reading: The Wild West of Performance Measurement appeared first on 'net work.
The post Worth Reading: Why I care about Segment Routing appeared first on 'net work.
Over at ipspace.net, Ivan is discussing using DNS to program firewall rules—
Could you use DNS names to translate human-readable rules into packet filters? The traditional answer was “no, because I don’t trust DNS”.
This has been a pet peeve of mine for some years—particularly after my time at Verisign Labs, looking at the DNS system, and its interaction with the control plane, in some detail. I’m just going to say this simply and plainly; maybe someone, somewhere, will pay attention—
The Domain Name System is a part of the IP networking stack.
Network engineers and application developers seem to treat DNS as some sort of red-headed-stepchild; it’s best if we just hide it in some little corner someplace, and hope someone figures out how to make it work, but we’re not going to act like it should or will work. We’re just going to ignore it, and somehow hope it goes away so we don’t have to deal with it.
Let’s look at some of the wonderful ideas this we’ll just ignore DNS has brought us over the years, like, “let’s embed the IP address in the packet someplace so we know who we’re talking to,” and “we Continue reading
The post Worth Reading: Predictive Policing appeared first on 'net work.
The post Worth Reading Digital Monoculture appeared first on 'net work.
The post Worth Reading: Elliptic Curve Cryptography and DNS appeared first on 'net work.
The post Worth Reading: Stop Trying to Change Users appeared first on 'net work.
The post Worth Reading: Why Google Gadgets are so Cheap appeared first on 'net work.
In last week’s post, the new BGP peer we’re tracing through the snaproute BGP code moved from open to openconfirmed by receiving, and processing, the open
message. In processing the open message, the list of AFIs this peer will support was built, the hold timer set, and the hold timer started. The next step is to move to established. RFC 4271, around page 70, describes the process as—
If the local system receives a KEEPALIVE message (KeepAliveMsg (Event 26)), the local system:
- restarts the HoldTimer and
- changes its state to Established.
In response to any other event (Events 9, 12-13, 20, 27-28), the local system:
- sends a NOTIFICATION with a code of Finite State Machine Error,
- sets the ConnectRetryTimer to zero,
- releases all BGP resources,
- drops the TCP connection,
- increments the ConnectRetryCounter by 1,
- (optionally) performs peer oscillation damping if the DampPeerOscillations attribute is set to TRUE, and
- changes its state to Idle.
For a bit of review (because this is running so long, you might forget how the state machine works), the way the snaproute code is written is as a state machine. The way the state machine works is Continue reading
The post Worth Reading: Creating a PCE Prototype appeared first on 'net work.
The post Worth Reading: Three great lies of cloud computing appeared first on 'net work.