New column -- Using IPsec for network protection

I'm now writing semi-regular articles for TechNet. These are part of the security management series, and they're also linked from the security newsletter.

The first column is a two-parter about IPsec. Part 1 describes the technology: how it operates, its various modes and methods, a bit on IKE, and how it works over NAT.

http://www.microsoft.com/technet/community/columns/secmgmt/sm121504.mspx

Part 2 illustrates three excellent scenarios that you can apply IPsec to today: stopping worms, protecting servers, and isolating domains -- a very cool approach for requiring domain membership of all your computers. Get rid of the rogues!

http://www.microsoft.com/technet/community/columns/secmgmt/sm0105.mspx

Security newsletter

If you haven't already, I urge you to sign up for the security newsletter. Hundreds of thousands of subscribers -- many of whom might be your competitors (LOL) -- already benefit from the tips, tricks, updates, guidance, and news we publish every month. So sign up today! My columns are always linked from here, too.

http://www.microsoft.com/technet/security/secnews/default.mspx

Published 10 February 05 09:59 by Steve Riley

Filed under: identity, authentication, access technologies, protection, configuration, IPsec

Comments

# Geir Johansen said on February 10, 2005 4:00 PM:: Thanks Steve! Been looking for something like this for a long time.

Great writing and easy to understand!

As a MCT teaching this subject next week I will sincerly recommend this for further reading in my "must have" url -LIST ;-)
# Sergey Simakov said on February 20, 2005 11:58 PM:: Steve, I think it is incorrectly to use term 'SHA1 or MD5 digital signature' then you describe authentication. Definitely one of the core properties of DigSig is that other party could not compute its own version and compare that with stored 'signature'
# Steve Riley said on February 27, 2005 5:24 PM:: No, my terminology is correct. It's the digital signataure that provides the per-packet authentication of the traffic. IOW, the signature authenticates that the packet actually comes from the sending IP address that's claiming to have sent the packet. When the receiving side computes its own version of the packet's signature, that second computation must match the same signature that's included in the packet.
# Sergey Simakov said on February 28, 2005 8:05 AM:: Well may be,
Let's check RFC 2406:
3.2.2 Authentication Algorithms
The authentication algorithm employed for the ICV computation is specified by the SA. For point-to-point communication, suitable authentication algorithms include keyed Message Authentication Codes (MACs) based on symmetric encryption algorithms (e.g., DES) or on one-way hash functions (e.g., MD5 or SHA-1). For multicast communication, one-way hash algorithms combined with asymmetric signature algorithms are appropriate, though performance and space considerations currently preclude use of such algorithms. ...
---
BUT in the real life I didn't see ANY IPSec implementation that used RSA or DSS _digital signature_ because nearly everyone uses HMAC (keyed MAC)
# Steve Riley said on March 2, 2005 11:12 AM:: Ah, I see your point. I am using the term "digital signature" more loosely here. You are technically correct, SHA-1 and MD5 are one-way hashes, not true digital signatures in the classic sense of that term. But the definition of the concept of "singing" has expanded to include hashing, too.
# tonyso said on May 31, 2005 11:32 AM:: So this guy goes into the doctor's office and says " Doctor, IPSec..." &lt;sound of phonograph needle...