Hello,

I have a question regarding selectors in IPsec.
I can't still fully understand it.

I know that I can setup some SAs. And then I define policy rules in SPD.
Then if a packet is being sent, SPD is consulted and according to selectors,
it is determined if IPsec should be applied.

But what I don't understand is that SPD entries does't point to a single SA
but only vaguely say that e.g. ESP should be used.
So how can I force to use some particular SA, if e.g three SAs with ESP
exists?

Maybe I am missing some basic principle, but could somebody explain it?

Thanks,
Jirka

In article <dls475$pn6$1@news.siemens.at>,
Jiri Klimes  <klimes@centrum.cz> wrote:
>Hello,

Hi!

>I know that I can setup some SAs. And then I define policy rules in SPD.
>Then if a packet is being sent, SPD is consulted and according to selectors,
>it is determined if IPsec should be applied.

Yes.

>But what I don't understand is that SPD entries does't point to a single SA
>but only vaguely say that e.g. ESP should be used.
>So how can I force to use some particular SA, if e.g three SAs with ESP
>exists?

It depends.

If you know the inner-selector fields, you can add the SAs with
inner-selector fields specified.  (You'd best be running S10, though, there
are bugs in S9 about this.)

>Maybe I am missing some basic principle, but could somebody explain it?

I hope that (specifying inner-selector fields) helps a little.

Can you tell me what problem are you trying to solve by adding multiple SAs
a priori of traffic?

--
Daniel L. McDonald  -  Solaris Networking & Security Engineering
Mail: danmcd@sun.com             |  * MY OPINIONS ARE NOT NECESSARILY SUN'S! *
1 Network Drive  Burlington, MA  |"rising falling at force ten
http://blogs.sun.com/danmcd/     | we twist the world and ride the wind" - Rush

Dan McDonald wrote:

> In article <dls475$pn6$1@news.siemens.at>,
> Jiri Klimes  <klimes@centrum.cz> wrote:
>>Hello,
> 
> Hi!
> 
>>I know that I can setup some SAs. And then I define policy rules in SPD.
>>Then if a packet is being sent, SPD is consulted and according to
>>selectors, it is determined if IPsec should be applied.
> 
> Yes.
> 
>>But what I don't understand is that SPD entries does't point to a single
>>SA but only vaguely say that e.g. ESP should be used.
>>So how can I force to use some particular SA, if e.g three SAs with ESP
>>exists?
> 
> It depends.
> 
> If you know the inner-selector fields, you can add the SAs with
> inner-selector fields specified.  (You'd best be running S10, though,
> there are bugs in S9 about this.)
> 

Yes, it was actually my question: How to specify selectors when creating an
SA. In examples of ipsecsey I've only seen parameters like protocol, dest
address, spi, algorithms and keys. So I've been a little bit confused.
But now after looking at man page, I see source address as well.
However what about ports? Can they be specified?

Anyway, what are the main differences in IPsec on solaris 8, 9 and 10? (what
bugs in S9?)
And how Opensolaris10 differs from solaris 10?

>>Maybe I am missing some basic principle, but could somebody explain it?
> 
> I hope that (specifying inner-selector fields) helps a little.
> 
> Can you tell me what problem are you trying to solve by adding multiple
> SAs a priori of traffic?

I simply want to create two (or more) SA, which differ only in spi and
source port.
And then I want to be able to say which one should be actually used for
outbound trafic.
Is this possible?

And yet another question arises in my mind?
In inboud trafic, a SA is selected by triple (SPI, dest address, protocol).
So how others selectors can be applied?

Thanks,
Jirka

Well since you asked for me by name... ;)


In article <dlvbsn$806$1@news.mch.sbs.de>,
Jiri Klimes  <klimes@centrum.cz> wrote:
>Dan McDonald wrote:
>
>Yes, it was actually my question: How to specify selectors when creating an
>SA. In examples of ipsecsey I've only seen parameters like protocol, dest
>address, spi, algorithms and keys. So I've been a little bit confused.
>But now after looking at man page, I see source address as well.
>However what about ports? Can they be specified?

Hmmm, looks like we have a man page bug.  The port/proto stuff should be
documented.

You can say "sport" and "dport", as well as "proto" when adding an IPsec SA
manually.  A way to see this in action is:

	- Set up IKE between two nodes that have "sa unique" on their
	  policy in ipsecconf(1m).

	- Send some traffic.

	- Utter "ipseckey -n save all" and see what's there.  "ipseckey save"
          always produces ipseckey(1m) input.

>Anyway, what are the main differences in IPsec on solaris 8, 9 and 10? (what
>bugs in S9?)
>And how Opensolaris10 differs from solaris 10?

That's a good question.  I should blog about this in more detail, but here's
the short story:

	Solaris 8
	---------
	- Basic AH/ESP support for IPv4.  (des/3des/md5/sha1)
	- Manual keying.
	- ipsecconf(1m) uses unidirectional-only syntax.
	- Most of RFC 2367 is in place for PF_KEY.

	Solaris 9
	---------
	- IPv6 manually-keyed (FCS).
	- New ciphers (blowfish/aes) for ESP.
	- Added IKE for IPv4 (FCS) and IPv6 (S9u5).
	- ipsecconf(1m) uses improved bidirectional syntax (FCS).
	- Hardware-accelerated IKE (PKCS#11 support) (S9u2).
	- Hardware IPsec with SCA 4000 (S9u5).
	- Hardware keystore for IKE keys with SCA 4000 (S9u5).

	Solaris 10
	----------
	- Lots of small tweaks (e.g. /etc/default/ipsec, datestamp on
	  ipseckey flush/dump/monitor)
	- IPsec use of S10's Encryption Framework (kernel) (FCS).
	  (user-encryption-framework used S9u5's features)
	- NAT-Traversal (draft-09 in FCS, RFC 394* in S10u1).
	- ip_drop_packet() used as common sink for failed IPsec packets.
	  (easy place to drop dtrace FBT probe!)
	- Full-time default use of PKCS#11/user-encryption-framework (S10u1).

	OpenSolaris
	-----------
	- libike and in.iked are not in OpenSolaris due to OEM code in
	  libike.  But in these builds are:
		- AES for IKE Phase I
		- PKCS#8 import to ikecert(1m).
	- Performance tunables in SPD and SADB.
	- More on the way (e.g. Tunnel Reform and full tunnel-mode
	  interoperability).

>I simply want to create two (or more) SA, which differ only in spi and
>source port.  And then I want to be able to say which one should be actually
>used for outbound trafic.  Is this possible?

It should be, but use S10 or later, because we fixed several bugs in the S10
timeframe relating to this.

>And yet another question arises in my mind?
>In inboud trafic, a SA is selected by triple (SPI, dest address, protocol).
>So how others selectors can be applied?

They can't, technically.  You *can* enforce after-the-fact, though.  Say I
have decrypted a packet successfully, but the ports/innner-proto don't match,
I can drop the packet.  See ipsec_check_ipsecin_unique() in spd.c to see
where we do this.

Hope this helps.
--
Daniel L. McDonald  -  Solaris Networking & Security Engineering
Mail: danmcd@sun.com             |  * MY OPINIONS ARE NOT NECESSARILY SUN'S! *
1 Network Drive  Burlington, MA  |"rising falling at force ten
http://blogs.sun.com/danmcd/     | we twist the world and ride the wind" - Rush

Dan McDonald wrote:

> 
> Well since you asked for me by name... ;)
> 
> 
> In article <dlvbsn$806$1@news.mch.sbs.de>,
> Jiri Klimes  <klimes@centrum.cz> wrote:
>>Dan McDonald wrote:
>>
>>Yes, it was actually my question: How to specify selectors when creating
>>an SA. In examples of ipsecsey I've only seen parameters like protocol,
>>dest address, spi, algorithms and keys. So I've been a little bit
>>confused. But now after looking at man page, I see source address as well.
>>However what about ports? Can they be specified?
> 
> Hmmm, looks like we have a man page bug.  The port/proto stuff should be
> documented.
> 
> You can say "sport" and "dport", as well as "proto" when adding an IPsec
> SA
> manually.  A way to see this in action is:
> 
> - Set up IKE between two nodes that have "sa unique" on their
> policy in ipsecconf(1m).
> 
> - Send some traffic.
> 
> - Utter "ipseckey -n save all" and see what's there.  "ipseckey save"
>           always produces ipseckey(1m) input.
> 

Hmm, port/proto stuff is really missing.
I also don't know how to use  port/proto stuff programmatically using PF_KEY
socket (which extension?).


>>Anyway, what are the main differences in IPsec on solaris 8, 9 and 10?
>>(what bugs in S9?)
>>And how Opensolaris10 differs from solaris 10?
> 
> That's a good question.  I should blog about this in more detail, but
> here's the short story:
> 
> Solaris 8
> ---------
> - Basic AH/ESP support for IPv4.  (des/3des/md5/sha1)
> - Manual keying.
> - ipsecconf(1m) uses unidirectional-only syntax.
> - Most of RFC 2367 is in place for PF_KEY.
> 
> Solaris 9
> ---------
> - IPv6 manually-keyed (FCS).
> - New ciphers (blowfish/aes) for ESP.
> - Added IKE for IPv4 (FCS) and IPv6 (S9u5).
> - ipsecconf(1m) uses improved bidirectional syntax (FCS).
> - Hardware-accelerated IKE (PKCS#11 support) (S9u2).
> - Hardware IPsec with SCA 4000 (S9u5).
> - Hardware keystore for IKE keys with SCA 4000 (S9u5).
> 
> Solaris 10
> ----------
> - Lots of small tweaks (e.g. /etc/default/ipsec, datestamp on
> ipseckey flush/dump/monitor)
> - IPsec use of S10's Encryption Framework (kernel) (FCS).
> (user-encryption-framework used S9u5's features)
> - NAT-Traversal (draft-09 in FCS, RFC 394* in S10u1).
> - ip_drop_packet() used as common sink for failed IPsec packets.
> (easy place to drop dtrace FBT probe!)
> - Full-time default use of PKCS#11/user-encryption-framework (S10u1).
> 
> OpenSolaris
> -----------
> - libike and in.iked are not in OpenSolaris due to OEM code in
> libike.  But in these builds are:
> - AES for IKE Phase I
> - PKCS#8 import to ikecert(1m).
> - Performance tunables in SPD and SADB.
> - More on the way (e.g. Tunnel Reform and full tunnel-mode
> interoperability).
> 

Thanks very much for the info. It would be very helpful for many people if
some (probably more detailed) documentation is available somewhere at sun
pages.


>>I simply want to create two (or more) SA, which differ only in spi and
>>source port.  And then I want to be able to say which one should be
>>actually
>>used for outbound trafic.  Is this possible?
> 
> It should be, but use S10 or later, because we fixed several bugs in the
> S10 timeframe relating to this.
> 

OK.
Unfortunately I am now forced to use S9.

>>And yet another question arises in my mind?
>>In inboud trafic, a SA is selected by triple (SPI, dest address,
>>protocol). So how others selectors can be applied?
> 
> They can't, technically.  You *can* enforce after-the-fact, though.  Say I
> have decrypted a packet successfully, but the ports/innner-proto don't
> match,
> I can drop the packet.  See ipsec_check_ipsecin_unique() in spd.c to see
> where we do this.

If I understand it correctly the packet is received and decrypted corectly,
but if there's no matching policy for it, the packet is dropped by the SPD.

Or the post check is left solely for application?
 
> Hope this helps.

Yes.
Your reactions are very helpful.

Jirka

In article <dnbu1k$9ua$1@news.mch.sbs.de>,
Jiri Klimes  <klimes@centrum.cz> wrote:
>> 
>> - Set up IKE between two nodes that have "sa unique" on their
>> policy in ipsecconf(1m).
>> 
>> - Send some traffic.
>> 
>> - Utter "ipseckey -n save all" and see what's there.  "ipseckey save"
>>           always produces ipseckey(1m) input.
>> 
>
>Hmm, port/proto stuff is really missing.

Huh?  Did you actually try this, and using "sa unique"?

You mention later you're on S9, so that may influence things.  Don't forget
to make sure you're on the latest S9 update too.

>I also don't know how to use  port/proto stuff programmatically using PF_KEY
>socket (which extension?).

The SADB_EXT_ADDRESS structure has all of what you need:

	- There's an sadb_address_proto field.

	- The sockaddr_{in,in6} you send with it has a port in it already.

>Thanks very much for the info. It would be very helpful for many people if
>some (probably more detailed) documentation is available somewhere at sun
>pages.

You mean with respect to what changed?  We have IPsec docs already - and they
do say what's new per release.

>> I can drop the packet.  See ipsec_check_ipsecin_unique() in spd.c to see
>> where we do this.
>
>If I understand it correctly the packet is received and decrypted corectly,
>but if there's no matching policy for it, the packet is dropped by the SPD.

Yes!  That's it!

>Or the post check is left solely for application?

No, the SPD will drop if the policy says to match ports, and the packet does
not.  When you get to S10, you can use the "ip:0:ipdrop" kstat to see what
sort of precise failure causes a packet to drop.

--
Daniel L. McDonald  -  Solaris Networking & Security Engineering
Mail: danmcd@sun.com             |  * MY OPINIONS ARE NOT NECESSARILY SUN'S! *
1 Network Drive  Burlington, MA  |"rising falling at force ten
http://blogs.sun.com/danmcd/     | we twist the world and ride the wind" - Rush