OpenSolaris

1. Community: OS/Net (ON)
   1. Blogs
   2. Development Process
   3. Developer's Reference
      1. Introduction
      2. Prerequisites
      3. The Source Tree, part 1
      4. The Source Tree, part 2
      5. Building OpenSolaris
      6. Installing and Testing OpenSolaris
      7. Integration Procedure
      8. Best Practices and Requirements
      9. Glossary
   4. Discussions
   5. Installation (from source) Quickstart
      1. Annotated nightly(1) Mail Example
   6. Currently Known Issues
   7. CRT
      1. Advocates & Sponsors
      2. Becoming a CRT Advocate
      3. Charter
      4. RTI nits to avoid
      5. Sponsor Tasks
      6. Becoming a Sponsor
   8. Schedule
   9. ONNV Flag Days, Heads Ups, and Project Integration History
      1. All
      2. Builds 91-95
      3. Builds 86-90
      4. Builds 81-85
      5. Builds 76-80
      6. Builds 71-75
      7. Builds 66-70
      8. Builds 61-65
      9. Builds 56-60
      10. Builds 51-55
      11. Builds 46-50
      12. Builds 41-45
      13. Builds 36-40
      14. Builds 31-35
      15. Builds 26-30
      16. Builds 21-25
   10. Leaders
   11. Observers
   12. Putback Logs
   13. Developing Solaris
       1. Quality Death Spiral
   14. wx
   15. findunref and unreferenced files
   16. Bourne/Korn Shell Coding Conventions

FLAG DAY: IPsec Tunnel Reform (PSARC 2005/516)

Date: Fri, 3 Nov 2006 10:07:24 -0500
From: Dan McDonald <danmcd at sun dot com>
To: onnv-gate at onnv dot eng dot sun dot com, on-all at eng dot sun dot com
Subject: FLAG DAY: IPsec Tunnel Reform (PSARC 2005/516)

Hello gatelings!

This putback (finally) completes the Solaris implementation of the IP
Security Architecture (RFC 2401 and friends).  Tunnel Mode IPsec selects
keying material and makes IKE negotiate IPsec SAs using the *inner* packet
contents of an IP-in-IP packet.  Our interoperability with other IPsec
implementations increases greatly with this project.

It constitutes a flag day because several user-kernel interfaces change for
this project, and making them consistent will allow IPsec to keep working
properly.  This is especially important if you're a punchin user.  BFU is
your friend, but if you "Install" kernels, make sure you get a matched set of
libike, libipsecutil, in.iked, ikeadm, ipseckey, ipsecconf, and ifconfig.  And
don't even try replacing a single TCP/IP module without bringing the whole wad
built out of $SRC/uts/common/inet with it.

Also, if you build kmem readers like lsof, you'll need to rebuild them.  We
touch one kernel structure that's known to have impact on lsof.

Ahh, speaking of punchin, we have been testing this out on both punchin
servers for a number of weeks.  When we putback NAT Traversal I said then:

	The putback of NAT-Traversal (soon to be an RFC, but in the meantime
	we're using specs from the latest Internet-Draft) eliminates 90% of
	the problems NAT boxes cause.  The only exception is that if there
	are multiple punchin clients behind a single NAT box, punchin will
	get very confused.

With Tunnel Reform running on a punchin server *and* client (along with the
1.3.2 or later client package), the multiple-clients-behind-one-IP problem
goes away (so long as the multiple clients do not share the same certificate),
thanks to proper Tunnel Mode processing.  Special thanks to Jan Setje-Eilers &
Liane Praza - who not only discovered the original problem, but also verified
its fix with Tunnel Reform.

Don't forget to use the appropriate mail aliases:

PUNCHIN QUESTIONS  -->  ipsec-punchin-interest at sun dot com

IPsec Technology Questions --> ipsec-interest at sun dot com

The IPsec Team --> ipsec-core at sun dot com

Thanks!
Dan & Paul