Subject: [anonsec] revision of proposed WG charter

From: Black_David at emc.com ([email-masked])
Date: Fri Nov 19 16:51:56 2004

> <hat off>
> If BTNS requires channel bindings, then it's not reducing deployment 
> effort, but increasing it. BTNS must be useful in the absence of channel 
> bindings -first-, IMO.
> <hat back on> 

I think this confuses several notions of required:
- Required to use: A bad idea, I agree that BTNS must be useful even
	if there's no higher level channel binding done.
- Required to implement: Probably not - some BTNS implementations
	will go into environments where there's no point in doing
	channel binding, so the requirements level for this
	might be better left to higher level protocols that
	want to support binding.
- Required to design: This is what I'd like to see in scope for
	the WG, so that those who want to implement channel bindings
	have a single document that says "compute this to bind to an
	IPsec SA".
I'm only advocating the latter (do the basic design work as opposed
to asserting that it could be done).  I don't think the whole problem
needs to be solved - I'm looking for instructions on how to compute
the bits that represent the channel and are the input to the higher
level protocol's binding implementation.

Thanks,
--David

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Joe Touch
> Sent: Friday, November 19, 2004 7:25 PM
> To: Discussions of anonymous Internet security.
> Subject: Re: [anonsec] revision of proposed WG charter
> 
> _______________________________________________
>

---

From: touch at ISI.EDU (Joe Touch)
Date: Fri Nov 19 22:24:24 2004

> 	have a single document that says "compute this to bind to an

<hat on>
Can you clarify this? I can't quite parse it - "BTNS requires channel 
bindings to design" - to design what?

> level protocol's binding implementation.

Is there some reason that would be different from the 'identity' - which 
others have mentioned could be derived from latter phases of DH?

Joe

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : http://www.postel.org/pipermail/anonsec/attachments/20041119/33d810f8/signature.bin

---

From: hartmans-ietf at mit.edu (Sam Hartman)
Date: Sat Nov 20 20:15:28 2004

>>>>> "Joe" == Joe Touch <[email-masked]> writes:

    Joe> Is there some reason that would be different from the
    Joe> 'identity' - which others have mentioned could be derived
    Joe> from latter phases of DH?

 No, David is claiming that we or someone else needs to specify the
 identity.  He is additionally claiming he wants the people doing the
 BTNS work to specify the identity.

Personally I think that bits from the DH exchange is one of the least
deployable identities we could choose.

---

From: paul.hoffman at vpnc.org (Paul Hoffman / VPNC)
Date: Sat Nov 20 20:30:29 2004

>deployable identities we could choose.

Of course. It's not being proposed as an "identity", but as a 
mechanism for channel binding. In that respect, it is better than 
even the public key of a self-signed cert because it is much less 
likely to be reusable.

--Paul Hoffman, Director
--VPN Consortium

---

From: hartmans-ietf at mit.edu (Sam Hartman)
Date: Sat Nov 20 20:38:29 2004

>>>>> "Paul" == Paul Hoffman / VPNC <[email-masked]> writes:

    Paul> At 11:15 PM -0500 11/20/04, Sam Hartman wrote:
    >> Personally I think that bits from the DH exchange is one of the
    >> least deployable identities we could choose.

    Paul> Of course. It's not being proposed as an "identity", but as
    Paul> a mechanism for channel binding. In that respect, it is
    Paul> better than even the public key of a self-signed cert
    Paul> because it is much less likely to be reusable.

I meant it was one of the least deployable solutions for channel
bindings.  Yes, it's great if you can make it work, but that seems
challenging.

--Sam

---

From: paul.hoffman at vpnc.org (Paul Hoffman / VPNC)
Date: Sun Nov 21 09:56:32 2004

>bindings.  Yes, it's great if you can make it work, but that seems

Hmmmm, I'm missing something then. Why is it easier to pass the 
self-signed certs from messages 5 and 6 (in IKEv1) up to the higher 
layer than it is to pass the DH public keys from messages 3 and 4?

--Paul Hoffman, Director
--VPN Consortium

---

From: sommerfeld at sun.com (Bill Sommerfeld)
Date: Mon Nov 22 06:29:35 2004

> layer than it is to pass the DH public keys from messages 3 and 4?

It's not going to be any harder to move the bits.

[FWIW, I have prototype running code which does this sort of information
pass-up].

The problem that several people alluded to is that IKE rekey may
conceptually occur at any time -- between any two packets.  Rather than
binding upper layers to a particular IKE or IPsec SA, we need a stable
identifier/name/... for the secure channel created by a sequence of IKE
SA's and/or IPsec SA's.

The certificate attributes of interest will be the same across rekey,
while the DH public keys will be different.

							- Bill

---

From: kent at bbn.com (Stephen Kent)
Date: Mon Nov 22 08:44:36 2004

>while the DH public keys will be different.

I think that is an excellent rationale for using the cert field of 
your choice as a stable ID.

Steve

---

From: touch at ISI.EDU (Joe Touch)
Date: Mon Nov 22 08:59:08 2004

> At 9:28 AM -0500 11/22/04, Bill Sommerfeld wrote:
...
> I think that is an excellent rationale for using the cert field of your 
> choice as a stable ID.
> 
> Steve

<hat off>
If the certificate isn't authenticated, then cert fields are not 
comparable across certs. I would expect that cert fields ought to be 
comparable only across certs with the same level of trust, as well.

I.e., this is rational for NOT using a 'stable ID' for anonymous mode, 
because it gives a false sense of cross-cert semantics.

Joe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : http://www.postel.org/pipermail/anonsec/attachments/20041122/911aa28a/signature.bin

---

From: Julien.Laganier at Sun.COM (Julien Laganier)
Date: Mon Nov 22 09:15:34 2004

On Monday 22 November 2004 17:58, Joe Touch wrote:
> >> The certificate attributes of interest will be the same across
> >> rekey, while the DH public keys will be different.
> >
> > I think that is an excellent rationale for using the cert field
> > of your choice as a stable ID.
> >
> > Steve
>
> <hat off>
> comparable across certs. I would expect that cert fields ought to
> be comparable only across certs with the same level of trust, as
> well.
>
> I.e., this is rational for NOT using a 'stable ID' for anonymous
> mode, because it gives a false sense of cross-cert semantics.

Hi Joe,

What about using a hash of either the public key or the Certificate as 
a stable ID?

Thanks,

--julien

---

From: paul.hoffman at vpnc.org (Paul Hoffman / VPNC)
Date: Mon Nov 22 09:27:35 2004

At 9:28 AM -0500 11/22/04, Bill Sommerfeld wrote:
>conceptually occur at any time -- between any two packets.

Correct.

>   Rather than

That's where I lose you. If we go with the way that most IKEv1 
implementers agreed, with a single long-lived Phase 1 that rekeys all 
of the Phase 2s, I don't see that "need" at all. I only see it in the 
confusing and poorly-interoperating case of short Phase 1s and long 
Phase 2s.

>while the DH public keys will be different.

The DH public of the Phase 1 remains constant.

--Paul Hoffman, Director
--VPN Consortium

---

From: touch at ISI.EDU (Joe Touch)
Date: Mon Nov 22 09:41:39 2004

> What about using a hash of either the public key or the Certificate as 

<hat off>
That might be useful to consider.

<BOF chair hat on>
IMO, this is down in the work of the WG. We should focus on clarifying 
the charter; as I recall, this thread emanated from the issue of how 
much to include specific issues of channel binding in thw charter.

It seems useful to mention that we should address how/whether BTNS 
affects or is affected by channel bindings as part of the charter.

Is there something more specific that needs to be included?

Joe

---

From: sommerfeld at sun.com (Bill Sommerfeld)
Date: Mon Nov 22 09:52:34 2004

> confusing and poorly-interoperating case of short Phase 1s and long 

I was not referring to that.

I work on systems intended to stay up indefinitely.

IPsec SA lifetimes will be long.
IKE SA lifetimes will be longer -- but they won't be infinite.

					- Bill

---

From: paul.hoffman at vpnc.org (Paul Hoffman / VPNC)
Date: Mon Nov 22 10:48:03 2004

>I work on systems intended to stay up indefinitely.

Ah. So, your assumption is that if a peer accepted the cert once, it 
will accept it again on better footing than starting from scratch. 
That's a reasonable model, but one that is much more complex than I 
think was being envisioned. The idea of the upper layer is going to 
pass an indication of "accept this cert for real (not for anon) in 
the future" back down to IPsec seems daunting, to say the least.

I think we should leave the problem at "get unauthenticated IPsec 
going first, authenticate as needed above" and leave it at that. It's 
much more tractable, and matches the problems that have been listed 
so far.

--Paul Hoffman, Director
--VPN Consortium

---

From: kent at bbn.com (Stephen Kent)
Date: Mon Nov 22 10:55:35 2004

At 8:58 AM -0800 11/22/04, Joe Touch wrote:
>Content-Type: multipart/signed; micalg=pgp-sha1;
>	protocol="application/pgp-signature";
>	boundary="------------enig5829EF626923B23DA8374947"
>
>
>
>Stephen Kent wrote:

Joe,

It is fair to note that anything other than the subject public key is 
unlikely to be guaranteed to be unique across self-signed certs, and 
thus suitablle for use across different IKE sessions. However, I 
think the analysis cited by Bill referred to continuity across one 
IKE session, but multiple child SAs or across child SA rekeying. 
This is one of the areas where we don't yet have a clear 
characterization of what BTNS is trying to accomplish, and it leads 
to confusion.

Steve

---

From: hartmans-ietf at mit.edu (Sam Hartman)
Date: Mon Nov 22 14:02:36 2004

Paul> At 12:51 PM -0500 11/22/04, Bill Sommerfeld wrote:
    >>> implementers agreed, with a single long-lived Phase 1 that
    >>> rekeys all of the Phase 2s, I don't see that "need" at all. I
    >>> only see it in the confusing and poorly-interoperating case of
    >>> short Phase 1s and long Phase 2s.

    Paul> Ah. So, your assumption is that if a peer accepted the cert
    Paul> once, it will accept it again on better footing than
    Paul> starting from scratch. That's a reasonable model, but one
    Paul> that is much more complex than I think was being
    Paul> envisioned. The idea of the upper layer is going to pass an

No, here's what happens.

* You pull up an anonymous SA

* You ask that SA what its identity is.

* You use some upper layer protocol to do your authentication and bind this authentication to the SA identity you extracted.

* You assert a policy that traffic over the upper layer channel in
  question (typically a TCP connection) be authenticated to the IPsec
  identity your upper layer authentication is bound to.

--Sam

---

From: paul.hoffman at vpnc.org (Paul Hoffman / VPNC)
Date: Mon Nov 22 14:48:37 2004

At 5:02 PM -0500 11/22/04, Sam Hartman wrote:
>* You use some upper layer protocol to do your authentication and 
>bind this authentication to the SA identity you extracted.
>

That works for me. So, I'm still confused. Why is binding to the 
public key in an self-signed cert passed in messages 5 and 6 better 
than binding to the DH public keys passed in messages 3 and 4? As 
long as the IKE SA is up, any of those keys are valid identifiers for 
the IKE SA.

The self-signed cert keys might get re-used later, but only if you 
pass them back to your IKE policy engine. The DH public keys are 
going to be unique to that one SA unless both parties blow it badly 
and re-use their DH primes.

--Paul Hoffman, Director
--VPN Consortium

---

From: hartmans-ietf at mit.edu (Sam Hartman)
Date: Mon Nov 22 15:00:38 2004

>>>>> "Paul" == Paul Hoffman / VPNC <[email-masked]> writes:

    Paul> That works for me. So, I'm still confused. Why is binding to the
    Paul> public key in an self-signed cert passed in messages 5 and 6 better
    Paul> than binding to the DH public keys passed in messages 3 and 4? As long
    Paul> as the IKE SA is up, any of those keys are valid identifiers for the
    Paul> IKE SA.

Bill is the one who convinced us all that limiting ourselves to one
IKE SA lifetime was a bad idea.

--Sam

---

From: sommerfeld at sun.com (Bill Sommerfeld)
Date: Mon Nov 22 15:01:49 2004

> long as the IKE SA is up, any of those keys are valid identifiers for 

I already answered this earlier today.

let me try to be more clear:

the IKE SA may expire (due to system policy on maximum IKE SA lifetime)
and be rekeyed at any time, between any arbitrary pair of packets.

Two communicating programs may be unaware that this is going on.  
one may pull the DH binding value from before the IKE rekey and the
other may pull the value from after the rekey.  they will attempt to
exchange authenticated channel binding messages, find a mismatch, and
report an auditable error event, needlessly raising alarm bells.

						- Bill

---

From: paul.hoffman at vpnc.org (Paul Hoffman / VPNC)
Date: Mon Nov 22 15:52:41 2004

>report an auditable error event, needlessly raising alarm bells.

OK, yes, that's much clearer. Sorry for the denseness.

In that case, re-using an identity (like the public key in the 
self-signed cert) is better than a non-reusable identity like the 
Phase 1 DH public. This will clearly be more common in IKEv2 where 
there is no negotiation of SA lifetime.

--Paul Hoffman, Director
--VPN Consortium

---

From: kent at bbn.com (Stephen Kent)
Date: Mon Nov 22 15:55:07 2004

>* You ask that SA what its identity is.

IKE asserts an ID for its SA, but not for child SAs, except to the 
extent that child SAs inherit the ID from the IKE SA. So, I could 
interpret this bullet to mean that you want to know the ID asserted 
for the parent IKE SA, when it was created. Is that correct?

>bind this authentication to the SA identity you extracted.

Does the upper layer protocol allow you to assert an identity?  Most 
do, because they are designed for stand-alone operation. If so, then 
what you have is an authenticated upper layer identity, plus an (IKE) 
SA identity, both iof which can be bound to the child SA in question. 
Is that the intent?

>   identity your upper layer authentication is bound to.

SPD policies specify access controls based on an authenticated 
identity, but they don't specify an authentication mechanism or 
criteria. That's the provenance of the PAD. But, the PAD entries do 
not refer to extant child SAs, just to IKE peers. Is there a good way 
to reword your last bullet consistent with these IPsec terms?

Steve

---

From: hartmans-ietf at mit.edu (Sam Hartman)
Date: Mon Nov 22 16:12:37 2004

>>>>> "Stephen" == Stephen Kent <[email-masked]> writes:

    >> * You ask that SA what its identity is.

    Stephen> IKE asserts an ID for its SA, but not for child SAs,
    Stephen> except to the extent that child SAs inherit the ID from
    Stephen> the IKE SA. So, I could interpret this bullet to mean
    Stephen> that you want to know the ID asserted for the parent IKE
    Stephen> SA, when it was created. Is that correct?

Yes.

    >> * You use some upper layer protocol to do your authentication
    >> and bind this authentication to the SA identity you extracted.

    Stephen> Does the upper layer protocol allow you to assert an
    Stephen> identity?  Most do, because they are designed for
    Stephen> stand-alone operation. If so, then what you have is an
    Stephen> authenticated upper layer identity, plus an (IKE) SA
    Stephen> identity, both iof which can be bound to the child SA in
    Stephen> question. Is that the intent?

I'm not convinced you can bind these to the child SA.

What I want out of the upper layer protocol is an assertion of the
form upper layer identity x maps to IKE parent identity y for this session.

    >> * You assert a policy that traffic over the upper layer channel
    >> in question (typically a TCP connection) be authenticated to
    >> the IPsec identity your upper layer authentication is bound to.

    Stephen> SPD policies specify access controls based on an
    Stephen> authenticated identity, but they don't specify an
    Stephen> authentication mechanism or criteria. That's the
    Stephen> provenance of the PAD. But, the PAD entries do not refer
    Stephen> to extant child SAs, just to IKE peers. Is there a good
    Stephen> way to reword your last bullet consistent with these
    Stephen> IPsec terms?

I don't see how the child SA entres into what I'm saying at all.

Let's assume that y is the IKE idenity I authenticated with my uper
layer protocol for tcp connection z.  I want to make a policy
assertion of the form all traffic over connection z must be to/from
ike peer y.

---

From: kent at bbn.com (Stephen Kent)
Date: Tue Nov 23 07:01:09 2004

>form upper layer identity x maps to IKE parent identity y for this session.

Who is the "I" in this case? Is it the upper layer protocol which 
needs to get a handle on the IKE SA, and a way to to ask if a given 
child SA is a child of a specified parent?

>assertion of the form all traffic over connection z must be to/from

The TCP connection over which you authenticated the peer is protected 
by a child SA, so the upper later protocol authentication is a 
function of that child SA.  But I still do not understand your last 
sentence. It seems that you want to assert (really infer) that the ID 
for the IKE peer is Y, based on having authenticated Y on a child SA 
associated with the IKE peer.

If the peer is a single user end system, it seems reasonable to infer 
an IKE peer identity from the child SA. But if it is a multi-user end 
system, that would be a bad inference and if the peer is a security 
gateway, it also may not be appropriate to infer the IKE peer ID from 
a given child SA's authentication.

Finally, you use the phrase "I want to make a policy assertion ..." 
I don't know how to interpret this. Who is the consumer of the policy 
assertion? Is is the application, or it is IPsec.  The former seems 
to be an issue outside the scope of IPsec; the latter can be 
dangerous, in general, because it is saying that IPsec, a lower layer 
security mechanism, is having it's access controls affected by an 
application, and that coukd undermine these controls relative to 
other applications, other users, etc.

Steve

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Tue Nov 23 13:00:44 2004

> because it gives a false sense of cross-cert semantics.

Using certs for unauthenticated IPsec allows only two things from the
cert to be "trusted:"  a) its public key (since 'proof' of possession of
the corresponding private key will come in the IKE phase-2/AUTH
exchanges) and b) its expiration date.

In any case, using no public key as an ID has problems when it comes to
re-keying, and using a naked public key w/o a cert means more changes
will be needed in the IKE protocols.

Cheers,

Nico
--

---

From: Nicolas.Williams at Sun.COM (Nicolas Williams)
Date: Tue Nov 23 13:05:43 2004

> That might be useful to consider.

And how is this different from what I've proposed?

In the ecumenical :) self-signed cert proposal we'd have the peer assert
its certificate's public key (or fingerprint thereof, or fingerprint of
the cert -- it's all more or less the same) as its ID and authenticate
that.

> much to include specific issues of channel binding in thw charter.

But since it's been argued that the use/non-use of certs in
unauthenticated IPsec is consistent/inconsistent with placing this work
in the PKI4IPSEC WG deciding this becomes important to deciding where
this work belongs.

Nico
--

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Tue Nov 23 13:06:42 2004

> the future" back down to IPsec seems daunting, to say the least.

I don't think Bill was talking about leap-of-faith sharing of certs.

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Tue Nov 23 13:08:44 2004

> and re-use their DH primes.

Suppose I suspend my laptop, then later -- much later, resume it and the
peer in question has expired the relevant SAs.  If the application is
still running on the peer then the suspend/resume event would not end
the connection if we use certs.  It would if we use ephemeral keys.

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Tue Nov 23 13:14:19 2004

> for the parent IKE SA, when it was created. Is that correct?

[speaking for myself]  Yes.

> SA identity, both iof which can be bound to the child SA in question. 

[speaking for myself]  Yes.

> to reword your last bullet consistent with these IPsec terms?

[speaking for myself]  I'm not sure.  But I know that this is what Bill
means by "connection latching."  To "bind" is such a useful verb...

Nico
--

---

From: touch at ISI.EDU (Joe Touch)
Date: Wed Nov 24 10:12:12 2004

Stephen Kent wrote:
| At 8:58 AM -0800 11/22/04, Joe Touch wrote:
|
|> Content-Type: multipart/signed; micalg=pgp-sha1;
|>     protocol="application/pgp-signature";
|>     boundary="------------enig5829EF626923B23DA8374947"
|>
|>
|>
|> Stephen Kent wrote:
|>
|>> At 9:28 AM -0500 11/22/04, Bill Sommerfeld wrote:
|>
|> ...
|>
|>>> The certificate attributes of interest will be the same across rekey,
|>>> while the DH public keys will be different.
|>>
|>>
|>> I think that is an excellent rationale for using the cert field of
|>> your choice as a stable ID.
|>>
|>> Steve
|>
|>
|> <hat off>
|> If the certificate isn't authenticated, then cert fields are not
|> comparable across certs. I would expect that cert fields ought to be
|> comparable only across certs with the same level of trust, as well.
|>
|> I.e., this is rational for NOT using a 'stable ID' for anonymous mode,
|> because it gives a false sense of cross-cert semantics.
|>
|> Joe
|
|
| Joe,
|
| It is fair to note that anything other than the subject public key is
| unlikely to be guaranteed to be unique across self-signed certs, and
| thus suitablle for use across different IKE sessions. However, I think
| the analysis cited by Bill referred to continuity across one IKE
| session, but multiple child SAs or across child SA rekeying. This is one
| of the areas where we don't yet have a clear characterization of what
| BTNS is trying to accomplish, and it leads to confusion.
|
| Steve

Is there something specific BTNS needs to accomplish in those contexts?
BTNS, IMO, focuses on the IKE session establishment. Subsequent
inheritance ought to refer back to a session identifier which is local
within the endpoint, and already needs to support both signed certs and
preshared keys. I'm not as familiar with the internals of IKE, but I
have two questions:

	1) are preshared keys represented as 'certificates' internally?
		if not, then, as Paul Hoffman notes, there's no special
		reason to limit outselves to self-signed certs as the
		only way to do anonymous mode

	2) how do child SAs refer back to the parent IKE session, or
	   how does rekeying refer to the ongoing session
		if not a cert or cert-derived field, it seems that
		these issues might not be affected by the use of
		anonymous IKE

Joe

---

From: kivinen at iki.fi (Tero Kivinen)
Date: Thu Nov 25 04:52:51 2004

> 	1) are preshared keys represented as 'certificates' internally?

No. For IKEv1 the preshared keys and certificates use completely
different protocol (i.e. the payload to put in the exchanges etc are
completely different, and so is also the things that is calculated
when the exchange is authenticated). 

> 		only way to do anonymous mode

If someone starts from scratch (i.e. no existing IKEv1 code), then if
we ask them to support both pre-shared keys and any signature based
methods (raw rsa keys or self-signed certs), then they need to write
more code, and do a lot more testing.

I think we should try to limit to only one authentication mode in the
IKEv1 (and I would hope it to be RSA signatures (whether we are using
bare keys or self-signed certs, does not really affect the actual
exchange)).

> 	   how does rekeying refer to the ongoing session

There is not real way to refer back to the parent IKE session in
IKEv1. Implementations uses things like, if you are renegotiating the
SA having same selectors than the old one then it is rekey, and then
they verify that you are allowed to do that by verifying the IKE SA
used to negotiate the IPsec SA, and checking that the SPD ssociated to
that IKE SA matches or something like that. The mapping from IKE SA to
the SPD is usually done throught the ID exchange inside the IKE
negotiation. 

> 		these issues might not be affected by the use of

If we can have stable unique IKE ID then we can do rekeys reliably.
I.e. the ID should be unique (i.e. no other host should have the same
ID), and it should be stable (i.e. the host uses same ID every time
it connects).

For public keys this is easy, we simply use the public key or the hash
of it as a ID.

If we want to offer secure binding of previous SAs to the new rekeyed
SAs, then the ID also needs to be something that nobody else can use.
Public key (or hash of it) fullfills also that, as to be able to use
that public key the attacker would need to know the private key. This
makes it so that only the owner of the private key can use that ID. 
-- 
[email-masked]

---

From: kent at bbn.com (Stephen Kent)
Date: Mon Nov 29 08:37:54 2004

At 10:10 AM -0800 11/24/04, Joe Touch wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>
>
>Stephen Kent wrote:

I am not an IKE implementor, but since pre-shared keys are secrets, 
not public keys, I would not expect them to be represented as certs 
internally.

>		these issues might not be affected by the use of

the answer to your first question is an internal issue that may vary 
from one implementation to the next. in IKEv2 I believe we added a 
facility to make it easier for one IKE peer to signal to the other 
when a new SA was intended as a replacement for an extant SA, since 
we also wanted to be able to establish and maintain multiple SAs with 
the same traffic selectors, to support ToS.

Steve