Date: Thu, 31 Jul 2003 22:10:21 -0400 From: Nick Holland To: "Misc @OpenBSD" Subject: IPsec FAQ Sorry for the overdue-ness of this note... I think I probably owe everyone a note about why I did the rather drastic act of blanking out an entire section of the FAQ without replacing it with anything. The section was obsolete and not being actively maintained in the way it needed to be: namely, when critical changes are made, that they get back into the FAQ. YES, there was a lot of good information in faq13.html, but there is also a lot of inaccurate info. I do not feel it is appropriate to expect users to guess what is good and what is not. The trickle of "fix this" "this changed" etc. that came in wasn't resulting in a good document, just something that was slightly less wrong. Yes, I want a new IPsec FAQ. I would welcome any old parts from the old faq13.html that are appropriate. However, based on the number of IPsec questions on the mail lists (and the resounding lack of "Read the FAQ, dammit!" responses), I don't think simply correcting what was there is sufficient. This is why I wiped it out, to free people from feeling they had to "tweak" the existing document. If there is good stuff from the old document you want, GREAT, it is in cvs, and it will remain there. But don't feel any need to retain any amount of it. Unfortunately, I do not have the qualifications to write a good IPsec document at this time, and the time required for me to get "up to speed" will basically prevent me from getting any other FAQ work done...and there is a LOT I want to do. So, I would like volunteers to help out on this. Some general thoughts: * Don't be afraid to look at the old IPsec FAQ, but don't be constrained by it, either. Maybe the new IPsec FAQ will be one file (i.e., faq13.html), maybe it will be a whole new subtree (like the new PF FAQ). Trick: Come up with content, figure out the layout the content suggests. It is an iterative process... content implies structure, structure implies content. * Practically speaking, this will probably end up being an individual or _really small team_ project. I really don't think we are going to get a coherent and clear and document one paragraph at a time from 40 people... * Show, don't talk. You have an idea, sketch it out and show me. Telling us how much you want a really, really good IPsec FAQ isn't going to change squat. * If you think you can pound out a new IPsec FAQ in an hour or two of work, you are sadly mistaken. A usable candidate for replacement will be a huge amount of work, I expect. * Examples and samples need to be tested. "this should work" is not acceptable. If you got to work with someone else to test some of this stuff out, DO IT. * I won't be holding the file name "faq13.html" open. If I finish another section before a new IPsec FAQ is in place, it will be called faq13.html. Worry about content, I'll figure out where to put it. * Try to follow existing FAQ style as best you can. * HOWTO is a dirty (non)word to me. The FAQ should be a teaching document, not a step-by-step recipe book. "Do this and it will work" is not what I'm after. When someone is finished reading an article in the FAQ, they should understand something, not just see a bunch of commands to type. * The wording and language used should be clear to non-native English speakers, and should be easily translated to other languages. Yes, that does take some of the fun out of the writing. 8-) If you wish to work on this, first step is outline your idea, and try to decide if it is really something you can do. Don't bother contacting me until you have an outline to show me. Due to the number of complete documents I get from people, I'll have to see some pretty substantial work before I'm going to "lock" this project down for one person/team. Nick. Subject: Re: IPsec FAQ From: "Brian A. Seklecki" To: nick@holland-consulting.net Cc: "Misc @OpenBSD" On Thu, 2003-07-31 at 22:10, Nick Holland wrote: > Sorry for the overdue-ness of this note... I think I probably owe > everyone a note about why I did the rather drastic act of blanking out > an entire section of the FAQ without replacing it with anything. > > The section was obsolete and not being actively maintained in the way > it needed to be: namely, when critical changes are made, that they get > back into the FAQ. YES, there was a lot of good information in > faq13.html, but there is also a lot of inaccurate info. I do not feel > it is appropriate to expect users to guess what is good and what is > not. > > The trickle of "fix this" "this changed" etc. that came in wasn't > resulting in a good document, just something that was slightly less > wrong. > > > Yes, I want a new IPsec FAQ. I would welcome any old parts from the > old faq13.html that are appropriate. However, based on the number of > IPsec questions on the mail lists (and the resounding lack of "Read > the FAQ, dammit!" responses), I don't think simply correcting what was > there is sufficient. This is why I wiped it out, to free people > from feeling they had to "tweak" the existing document. If there is > good stuff from the old document you want, GREAT, it is in cvs, and it > will remain there. But don't feel any need to retain any amount of > it. > > > Unfortunately, I do not have the qualifications to write a good IPsec > document at this time, and the time required for me to get "up to > speed" will basically prevent me from getting any other FAQ work > done...and there is a LOT I want to do. > > So, I would like volunteers to help out on this. > > Some general thoughts: > * Don't be afraid to look at the old IPsec FAQ, but don't be > constrained by it, either. Maybe the new IPsec FAQ will be one file > (i.e., faq13.html), maybe it will be a whole new subtree (like the new > PF FAQ). Trick: Come up with content, figure out the layout the > content suggests. It is an iterative process... content implies > structure, structure implies content. [...] > * HOWTO is a dirty (non)word to me. The FAQ should be a teaching > document, not a step-by-step recipe book. "Do this and it will work" > is not what I'm after. When someone is finished reading an article in > the FAQ, they should understand something, not just see a bunch of > commands to type. > * The wording and language used should be clear to non-native English > speakers, and should be easily translated to other languages. Yes, > that does take some of the fun out of the writing. 8-) At some point a Howto becomes a FAQ, a FAQ becomes a tutorial, and tutorial can easily snowball into a book. Books could, and have been written on IPsec using ISKAMP/IKE alone. What limitations on the depth and scope of the document will you be defining for volunteers? > > If you wish to work on this, first step is outline your idea, and try > to decide if it is really something you can do. Don't bother > contacting me until you have an outline to show me. Due to the number > of complete documents I get from people, I'll have to see some pretty > substantial work before I'm going to "lock" this project down for one > person/team. > > > Nick. -- Thanks, -Brian Subject: Re: IPsec FAQ From: "Brian A. Seklecki" To: "Brian A. Seklecki" Cc: nick@holland-consulting.net, "Misc @OpenBSD" On Tue, 2003-08-05 at 04:08, Brian A. Seklecki wrote: Okay here's my proposed outline: Hopefully this constitutes less "telling you what i want" and more "showing you". -------------------------------------------------------------------- -- Introduction to IPSec -- *) What is IPSec? *) Why IPSec? - Confidentiality, Integrity, Authenticity, Replay protection - A quick tcpdump(8) |'d to tcpshow(1) capturing a POP3, SMTP, or telnet session on an ethernet segment. - *HOW* IPSec provides protection *) IPSec / VPN a means, not an end *) IPSec a small part of a security policy *) IPSEc VPNs v.s. L2TP or PPTP *) Manual keyring v.s. isakmpd(8) *) --- Detailed explanations (possible use of graphical explanations) --- *) Define: SAs, the SAD, SPD, SPI and other useful acronyms *) Phase 1 v.s. Phase 2 *) Phase 1: Quick v.s. Aggressive mode *) ESP v.s. AH *) Diffie-Hellman key exchange explained *) Ph 1 Authentication: Pre-shared, X.509 certs, RSA keys w/o cert - How PKI/CA Certificate authentication differs from pre-shared keys - Graphical explanation *) Choosing phase 1 and phase 2 lifetimes - Time or bytes *) Defining Custom Transforms: - Use built in templates - Define your own? *) Defining your own transform sets - Encryption: DES, 3DES, Blowfish - Authenticity: MD5_HMAC or SHA1_HMAC - Using PFS group 1 or 2 - Tunnel or transport mode --- Planning for isakmpd(8) configuration: --- *) Planning is everything! *) Understanding existing network configuration - IP Addressing reference - CIDR Reference *) New install? Upgrade? Platform change? *) Perimeter router considerations? Access lists. *) Setting sysctl's *) The isakmpd.conf and isakmpd.policy layout --- Scaling IPSec: Using a CA to manage Certificates: --- *) Use of OpenBSD: - Support considerations. - Office Politics, Job security, etc >:} *) Using a commercial CA?! (mmm, maybe not) *) Self-Signing certificates instead using a CA - Why that's *) Running a private PKI CA - Security and trust factors - Technical aspect *) Setting up a CA *) Enrolling new devices. - Generating an RSA key pair - Generating a Certificate Signing Reuqest - Signing certs - using certpatch(8) to add ID info - Choosing an appropriate ID Type: FQDN, UFQDN, IPV4_ADDR *) Maintaining an up-to-date CRL on production systems -- Debugging techniques --- *) out-of-band management considerations *) using the -D flag properly *) how to interpret debugging output *) using ipecadm(8) to examine different SAs *) netstat -f encap and netstat -s output *) analyzing tcpdump(8) output *) Getting help - Mailing list archives - How to post a new problem to the list (what to include) *) Most commonly asked questions and frequently seen errors --- Special situations: --- *) IPSec and pf(4)/NAT *) IPSec and 802.11[a,b,g] *) Running multiple instances of isakmpd(8) on a multi-homed/multi-interface system with -f and -p flags *) Monitoring - SNMP - sending traps upon SA removal - ICMP Pings *) Crypto accelerator cards *) isakmpd(8) on non-OpenBSD systems --- Example Configurations --- *) Detailed network diagrams *) Known working example configurations *) Example 1: A two facility point-to-point configuration with an OpenBSD network "appliance" doing routing, NAT, Firewalling, and IPSec VPN. - ESP, pre-shared keys, tunnel mode - Variation: "Extranet" version where two organizations are connected via private WAN connectivity (a good AH-only use example!) *) Example 2: A mobile user configuration. An OpenBSD box in a dirty DMZ on an organization's LAN acting as a "VPN concentrator" as a tunnel endpoint from mobile users and tele-workers on 3rd party IP connections with dynamic IP addressing *key* - ESP, x.509 certificates, transport mode *) Example 3: Two large organizations. Perimeter router and Firewall on either end as physically and logically different units. - ESP, RSA keys, Tunnel mode --- References and Related Documentation -- *) URLs *) RFCs *) Man pages *) Books Subject: Re: IPsec FAQ (complete) From: "Brian A. Seklecki" To: "Misc @OpenBSD" Sorry about the duplication, too much caffeine and I jumped the gun on the send! -------------------------------------------------------------------- -- OpenBSD IPSec FAQ Layout ---------------------------------------- -------------------------------------------------------------------- -- Introduction to IPSec -- *) What is IPSec? *) Why IPSec? - Confidentiality, Integrity, Authenticity, Replay protection - ON the wire revisited: A quick tcpdump(8) |'d to tcpshow(1) capturing a POP3, SMTP, or telnet session - *HOW* IPSec provides protection (brief) *) IPSec / VPN a means, not an end *) IPSec a small part of a security policy *) IPSEc VPNs v.s. L2TP or PPTP *) "Tunneling" and "Encapsulation" defined - Using RFC 1918 space *) Manual keyring v.s. isakmpd(8) --- Detailed explanations (possible use of graphical explanations) --- *) Define: SAs, the SAD, SPD, SPI and other useful acronyms *) Phase 1 v.s. Phase 2 *) Phase 1: Quick v.s. Aggressive mode *) ESP v.s. AH Defined *) Tunnel v.s. Transport Mode Define *) Diffie-Hellman key exchange explained *) Ph 1 Authentication: Pre-shared, X.509 certs, RSA keys w/o cert - How PKI/CA Certificate authentication differs from pre-shared keys - Graphical explanation - Detailed explanation of trust relationships *) Choosing phase 1 and phase 2 lifetimes - Time or bytes - Practical examples *) Defining Custom Transforms: - Use built in templates - Define your own? *) Defining your own transform sets - Encryption: DES, 3DES, Blowfish - Authenticity: MD5_HMAC or SHA1_HMAC - Using PFS group 1 or 2 - Tunnel or transport mode --- Planning for isakmpd(8) configuration: --- *) Planning is everything! *) Understanding existing network configuration - Document the existing network configuration - IP Addressing reference - CIDR Reference *) New install? Upgrade? Platform change? *) Perimeter router considerations? Access lists and firewall rules *) Determine WAN connectivity type *) Determine RFC 1918 space to be used *) Setting sysctl's *) /etc/rc.conf changes *) Other system considerations: clock accuracy and synchronization *) The isakmpd.conf and isakmpd.policy layout --- Scaling IPSec: Using a CA to manage Certificates: --- *) Use of OpenBSD: - Support considerations. - Office Politics, Job security, etc >:} *) Using a commercial CA?! (mmm, maybe not) *) Self-Signing certificates instead using a CA - Why that's probably a bad idea *) Running a private PKI CA - Security and trust factors - Technical aspect *) Setting up a CA *) New device enrollment procedures: - Generating an RSA key pair - Generating a Certificate Signing Reuqest - Signing certs - using certpatch(8) to add ID info - Choosing an appropriate ID Type: FQDN, UFQDN, IPV4_ADDR *) Maintaining an up-to-date CRL on devices -- Debugging techniques --- *) out-of-band management considerations *) using the -D flag properly *) how to interpret debugging output *) using ipecadm(8) to examine different SAs *) ping, traceroute *) netstat -f encap and netstat -s output *) analyzing tcpdump(8) output *) Getting help - Mailing list archives - How to post a new problem to the list (what to include) *) Most commonly asked questions and frequently seen errors --- Special considerations: --- *) IPSec and pf(4)/NAT *) IPSec and 802.11[a,b,g] *) Running multiple instances of isakmpd(8) on a multi-homed/multi-interface system with -f and -p flags *) Monitoring - SNMP - sending traps upon SA removal - ICMP Pings *) Crypto accelerator cards *) isakmpd(8) on non-OpenBSD systems *) isakmpd(8) talking to non-OpenBSD systems - Gotchas for different vendors *) pf(4) and enc(4) *) IPv6 --- Example Configurations --- *) Detailed network diagrams *) Known working example configurations *) Example 1: A two facility point-to-point configuration with an OpenBSD network "appliance" doing routing, NAT, Firewalling, and IPSec VPN. - ESP, pre-shared keys, tunnel mode - Variation: "Extranet" version where two organizations are connected via private WAN connectivity (a good AH-only use example!) *) Example 2: A mobile user configuration. An OpenBSD box in a dirty DMZ acting as a "VPN concentrator" for tunnel endpoints from mobile users and tele-workers on 3rd party IP connections with dynamic IP addressing *key* - ESP, x.509 certificates, transport mode *) Example 3: Two large organizations. Perimeter router and Firewall on either end as physically and logically different units. - ESP, RSA keys, Tunnel mode, NAT, etc. --- References and Related Documentation -- *) URLs *) RFCs *) Man pages *) Books Date: Thu, 4 Sep 2003 10:11:52 -0400 (EDT) From: "Brian A. Seklecki" To: "Misc @OpenBSD" Subject: Re: IPsec FAQ (complete) On Tue, 5 Aug 2003, Brian A. Seklecki wrote: Some people have e-mailed me to inquire where they might find this document. I've had to break the bad news. Anyway, just for the record: I'm still dedicated to writing it. I'll need to assemble a small lab in order to properly test some example configurations, and that's on hold due to some budgetary constraints (I'm waiting to hear back from a new potential employer). -lava > > -------------------------------------------------------------------- > -- OpenBSD IPSec FAQ Layout ---------------------------------------- > -------------------------------------------------------------------- > > -- Introduction to IPSec -- > > *) What is IPSec? > *) Why IPSec? > - Confidentiality, Integrity, Authenticity, Replay protection > - ON the wire revisited: A quick tcpdump(8) |'d to tcpshow(1) > capturing a POP3, SMTP, or telnet session > - *HOW* IPSec provides protection (brief) > *) IPSec / VPN a means, not an end > *) IPSec a small part of a security policy > *) IPSEc VPNs v.s. L2TP or PPTP > *) "Tunneling" and "Encapsulation" defined > - Using RFC 1918 space > *) Manual keyring v.s. isakmpd(8) > > --- Detailed explanations (possible use of graphical explanations) --- > > *) Define: SAs, the SAD, SPD, SPI and other useful acronyms > *) Phase 1 v.s. Phase 2 > *) Phase 1: Quick v.s. Aggressive mode > *) ESP v.s. AH Defined > *) Tunnel v.s. Transport Mode Define > *) Diffie-Hellman key exchange explained > *) Ph 1 Authentication: Pre-shared, X.509 certs, RSA keys w/o cert > - How PKI/CA Certificate authentication differs from > pre-shared > keys > - Graphical explanation > - Detailed explanation of trust relationships > *) Choosing phase 1 and phase 2 lifetimes > - Time or bytes > - Practical examples > *) Defining Custom Transforms: > - Use built in templates > - Define your own? > *) Defining your own transform sets > - Encryption: DES, 3DES, Blowfish > - Authenticity: MD5_HMAC or SHA1_HMAC > - Using PFS group 1 or 2 > - Tunnel or transport mode > > --- Planning for isakmpd(8) configuration: --- > > *) Planning is everything! > *) Understanding existing network configuration > - Document the existing network configuration > - IP Addressing reference > - CIDR Reference > *) New install? Upgrade? Platform change? > *) Perimeter router considerations? Access lists and firewall rules > *) Determine WAN connectivity type > *) Determine RFC 1918 space to be used > *) Setting sysctl's > *) /etc/rc.conf changes > *) Other system considerations: clock accuracy and synchronization > *) The isakmpd.conf and isakmpd.policy layout > > > --- Scaling IPSec: Using a CA to manage Certificates: --- > > *) Use of OpenBSD: > - Support considerations. > - Office Politics, Job security, etc >:} > *) Using a commercial CA?! (mmm, maybe not) > *) Self-Signing certificates instead using a CA > - Why that's probably a bad idea > *) Running a private PKI CA > - Security and trust factors > - Technical aspect > *) Setting up a CA > *) New device enrollment procedures: > - Generating an RSA key pair > - Generating a Certificate Signing Reuqest > - Signing certs > - using certpatch(8) to add ID info > - Choosing an appropriate ID Type: FQDN, UFQDN, IPV4_ADDR > *) Maintaining an up-to-date CRL on devices > > > -- Debugging techniques --- > > *) out-of-band management considerations > *) using the -D flag properly > *) how to interpret debugging output > *) using ipecadm(8) to examine different SAs > *) ping, traceroute > *) netstat -f encap and netstat -s output > *) analyzing tcpdump(8) output > *) Getting help > - Mailing list archives > - How to post a new problem to the list (what to include) > *) Most commonly asked questions and frequently seen errors > > > --- Special considerations: --- > > *) IPSec and pf(4)/NAT > *) IPSec and 802.11[a,b,g] > *) Running multiple instances of isakmpd(8) on a > multi-homed/multi-interface system with -f and -p flags > *) Monitoring > - SNMP - sending traps upon SA removal > - ICMP Pings > *) Crypto accelerator cards > *) isakmpd(8) on non-OpenBSD systems > *) isakmpd(8) talking to non-OpenBSD systems > - Gotchas for different vendors > *) pf(4) and enc(4) > *) IPv6 > > --- Example Configurations --- > > *) Detailed network diagrams > *) Known working example configurations > > *) Example 1: A two facility point-to-point configuration with an > OpenBSD network "appliance" doing routing, NAT, Firewalling, and IPSec > VPN. > - ESP, pre-shared keys, tunnel mode > - Variation: "Extranet" version where two organizations are > connected via private WAN connectivity (a good AH-only use > example!) > > *) Example 2: A mobile user configuration. An OpenBSD box in a dirty > DMZ acting as a "VPN concentrator" for tunnel endpoints from mobile > users and tele-workers on 3rd party IP connections with dynamic IP > addressing *key* > > - ESP, x.509 certificates, transport mode > > *) Example 3: Two large organizations. Perimeter router and Firewall on > either end as physically and logically different units. > > - ESP, RSA keys, Tunnel mode, NAT, etc. > > --- References and Related Documentation -- > > *) URLs > *) RFCs > *) Man pages > *) Books > l8* -lava x.25 - minix - bitnet - plan9 - 110 bps - ASR 33 - base8