Subject: [anonsec] SAB without connection latching

From: hartmans-ietf at mit.edu (Sam Hartman)
Date: Sun, 04 Dec 2005 10:47:59 -0500

Nico has partially described a feature called connection latching that
allows a native mode IPsec implementation to guarantee that the same
peer ID is used for every packet sent over a particular connection.
It seems fairly clear that BTNS benefits significantly from this
technology.

The applicability statement makes the claim that BTNS protects against
on-path attacks after the connection is established.  In order to do
that we need to have some form of something like connection latching
even in non-native implementations.  

If we do nothing then the SA from one BTNS peer could be replaced by a
SA from another BTNS peer and the traffic on the connection would be
funneled over that SA.

It seems like we're going to need something like mini-leap-of-faith in
which we require that the identity of a peer remain constant for
traffic protected by a btns SA.

The obvious implementation to me seems to be something like:

1) Establish some sort of timer for packets going over the SA.  If the
   connection appears to still be alive, then require that we maintain
   the same peer identity.

2) If for some reason we have to drop such an SA, install a temporary
   discard rule for some period of time to make sure that we kill off
   the connection.

Note that I'm talking in very general terms about what behavior we
want.  I'm not talking about specific changes to the processing model,
to the PAD or SPD.  I realize that in order to be useful we eventually
need to get to that level of detial.  I also realize that when we
close the loop and get to that level of detail we may find we change
our requirements in order to be more consistent with the IPsec
architecture.  At this point though I'd like to hear what people think
about the required behavior in non-native implementations.

--Sam

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Sun, 4 Dec 2005 14:41:28 -0600

> on-path attacks after the connection is established.  In order to do
  ^^
off-path, not on-path.  If the applicability statement says "on-path"
then that's got to be a mistake.

And passive attacks.

To protect against more active attacks requires additional features,
such as connection latching and channel binding, or, where workable,
leap-of-faith.

Nico
--

---

From: hartmans-ietf at mit.edu (Sam Hartman)
Date: Sun, 04 Dec 2005 16:42:38 -0500

>>>>> "Nicolas" == Nicolas Williams <Nicolas.Williams at sun.com> writes:

    Nicolas> On Sun, Dec 04, 2005 at 10:47:59AM -0500, Sam Hartman
    Nicolas> wrote:
    >> The applicability statement makes the claim that BTNS protects
    >> against on-path attacks after the connection is established.
    >> In order to do
    Nicolas>   ^^ off-path, not on-path.  If the applicability
    Nicolas> statement says "on-path" then that's got to be a mistake.

no, I'm fairly sure that protecting against on-path attacks after the
connection is established is a goal of SAB.

The entire point of my message is that in order to do that we need to
do something more complicated than the most trivial possible vision of
SAB.

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Sun, 4 Dec 2005 18:11:08 -0600

> do something more complicated than the most trivial possible vision of

Oh, right, "other on-path attacks after key exchange."

Yes, I don't see how that can work w/o connection latching and/or
leap-of-faith.

Nico
--

---

From: pekka.nikander at nomadiclab.com (Pekka Nikander)
Date: Mon, 5 Dec 2005 14:23:05 +0100

> traffic protected by a btns SA.

I agree that such a feature would be very useful.

> .... At this point though I'd like to hear what people think

What you describe above, with suitable administrative interfaces,
sounds fine to me.  But then, personally, I am not that interested
in non-native implementations.  Hence, I would also be happy to
see the threats just documented, without requiring that non-native
BTNS provide the equivalent of connection latching.

--Pekka

---

From: kent at bbn.com (Stephen Kent)
Date: Mon, 5 Dec 2005 11:36:27 -0500

I'll just note that  2401bis (soon to be issued as 4301, yeah!) 
adopts a processing model that relies on decorrelation to simplify 
and speed up processing in SG and BITW implementations. Making 
frequent changes to the SPD, as suggested in your message, may be 
computationally costly.

Steve

---

From: hartmans-ietf at mit.edu (Sam Hartman)
Date: Mon, 05 Dec 2005 12:13:16 -0500

>>>>> "Stephen" == Stephen Kent <kent at bbn.com> writes:

    Stephen> I'll just note that 2401bis (soon to be issued as 4301,
    Stephen> yeah!) adopts a processing model that relies on
    Stephen> decorrelation to simplify and speed up processing in SG
    Stephen> and BITW implementations. Making frequent changes to the
    Stephen> SPD, as suggested in your message, may be computationally
    Stephen> costly.

noted.  do you have any other approaches you think we should look at?

--Sam

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Mon, 5 Dec 2005 12:36:24 -0600

> frequent changes to the SPD, as suggested in your message, may be 

Even when done only on BITS or native implementations?

---

From: hartmans-ietf at mit.edu (Sam Hartman)
Date: Mon, 05 Dec 2005 14:29:42 -0500

>>>>> "Nicolas" == Nicolas Williams <Nicolas.Williams at sun.com> writes:

    Nicolas> On Mon, Dec 05, 2005 at 11:36:27AM -0500, Stephen Kent
    Nicolas> wrote:
    >> adopts a processing model that relies on decorrelation to
    >> simplify and speed up processing in SG and BITW
    >> implementations. Making frequent changes to the SPD, as
    >> suggested in your message, may be computationally costly.

    Nicolas> Even when done only on BITS or native implementations?

As I understand it, it is an optimization any IPsec implementation may
choose to use.  As best I can tell the text is constructed so that it
is purely a performance issue.  So, you can choose to do it in your
implementation; lookups get faster and changes get slower.

You could presumably choose to do anything else provided that it was
externally the same.

---

From: kent at bbn.com (Stephen Kent)
Date: Mon, 5 Dec 2005 13:42:22 -0500

>noted.  do you have any other approaches you think we should look at?

I think David's suggestion, to manage the inactivity timeout via the 
SAD, vs. the SPD, might be good.

Steve

---

From: kent at bbn.com (Stephen Kent)
Date: Mon, 5 Dec 2005 15:13:04 -0500

>Even when done only on BITS or native implementations?

I said SGs and BITW. BITS is also an issue.

Native, end-system implementations, because they can take advantage 
of the socket interface info, don't benefit as much from 
de-correlations, so I don't see this as an issue in that context.

Steve

---

From: kent at bbn.com (Stephen Kent)
Date: Mon, 5 Dec 2005 15:14:09 -0500

>You could presumably choose to do anything else provided that it was

You are correct.

Steve

---

From: hartmans-ietf at mit.edu (Sam Hartman)
Date: Mon, 05 Dec 2005 16:32:59 -0500

>> noted.  do you have any other approaches you think we should

    Stephen> I think David's suggestion, to manage the inactivity
    Stephen> timeout via the SAD, vs. the SPD, might be good.

Ok.  I thought I tried to be clear I was talking about what I wanted
to accomplish not about how we actually accomplish. it.  I'd rather
not get stuck on details of where the inactivity timer goes at this
point and I'm sorry I included details that were not required in my
talking peace.

--Sam

---

From: touch at ISI.EDU (Joe Touch)
Date: Mon, 05 Dec 2005 15:09:01 -0800

> SA from another BTNS peer and the traffic on the connection would be

Can't that happen with existing IPsec already? i.e., to replace one SA
with another, signed in different ways? (different CAs, etc.)

> traffic protected by a btns SA.

Isn't that a requirement of existing IPsec implementations already, as
per above?

Joe

---

From: hartmans-ietf at mit.edu (Sam Hartman)
Date: Mon, 05 Dec 2005 18:35:27 -0500

>>>>> "Joe" == Joe Touch <touch at ISI.EDU> writes:

    Joe> Sam Hartman wrote:
    >>  Nico has partially described a feature called connection
    >> latching that allows a native mode IPsec implementation to
    >> guarantee that the same peer ID is used for every packet sent
    >> over a particular connection.  It seems fairly clear that BTNS
    >> benefits significantly from this technology.
    >> 
    >> In order to do that we need to have some form of something like
    >> connection latching even in non-native implementations.
    >> 
    >> If we do nothing then the SA from one BTNS peer could be
    >> replaced by a SA from another BTNS peer and the traffic on the
    >> connection would be funneled over that SA.

    Joe> Can't that happen with existing IPsec already? i.e., to
    Joe> replace one SA with another, signed in different ways?
    Joe> (different CAs, etc.)

Yes, but only when such a replacement is consistent with the PAD.
I.E. in general it needs to be the same peer within the definitions of
same based on trust anchors etc.

    >> It seems like we're going to need something like
    >> mini-leap-of-faith in which we require that the identity of a
    >> peer remain constant for traffic protected by a btns SA.

    Joe> Isn't that a requirement of existing IPsec implementations
    Joe> already, as per above?

No.

basically it can happen with existing IPsec implementations but is not
actually a security problem for anything besides BTNS.

---

From: touch at ISI.EDU (Joe Touch)
Date: Mon, 05 Dec 2005 15:59:11 -0800

> same based on trust anchors etc.

The PAD should be established when you connect (i.e., as a result of the
IKE, rather than to verify the IKE), and leave it in place until the
association is explicitly torn down. That entry would then prevent
hijacking as per above the same way as any other PAD entry, right?

> actually a security problem for anything besides BTNS.

The security issue seems to be whether the PAD should be modified while
there are SAs open that are governed by that PAD. I didn't see whether
2401bis addressed that issue, but it seems independent of BTNS at that
point.

Joe

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Mon, 5 Dec 2005 18:10:47 -0600

On Mon, Dec 05, 2005 at 03:59:11PM -0800, Joe Touch wrote:
> Sam> Yes, but only when such a replacement is consistent with the PAD.
> Sam> I.E. in general it needs to be the same peer within the
> Sam> definitions of same based on trust anchors etc.
> 

The problem lies in "until the association is explicitly torn down."

If that effectively means "forever" or "until someone complains" then
that's not good.

That's what would happen if the peer making the leap-of-faith PAD entry
allows leap-of-faith PAD entries to be made for dynamically addressed
nodes .

> 2401bis addressed that issue, but it seems independent of BTNS at that

No, the SAs might expire due to lack of traffic, but the traffic flows
might continue to exist, logically.  Thus allowing the PAD entry to be
removed as a result of SA expiration would be bad.

Problem:  How can non-native IPsec implementations know whether the
          associated traffic flows continue to exist?

Problem:  Given applications that use multiple connections between the
	  same two peers, how can even native IPsec implementations know
	  whether the associated traffic flows continue to exist?

Nico
--

---

From: touch at ISI.EDU (Joe Touch)
Date: Mon, 05 Dec 2005 16:16:59 -0800

> 	  whether the associated traffic flows continue to exist?

Don't all these problems exist for existing PAD entries?

Or is the PAD assumed static for all time? Any changes to the PAD can
cause similar problems...

Joe

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Mon, 5 Dec 2005 18:21:28 -0600

> Don't all these problems exist for existing PAD entries?

Maybe for some of them, but certainly not all.

If you have peers asserting IP address type IDs and they have certs with
iPAddress subject alternative names and you can validate said certs to
some trust anchor specified in the PAD entry, then you can have a PAD
entry that matches any peer asserting an IP address ID that won't have
this problem.

> cause similar problems...

Yes, changes to the PAD can cause problems.

Connection latching mitigates this, to some extent (i.e., not
necessarily for applications that use many connections between two
peers).

Nico
--

---

From: touch at ISI.EDU (Joe Touch)
Date: Tue, 06 Dec 2005 09:05:46 -0800

> then that's got to be a mistake.

It's not a mistake.

> such as connection latching and channel binding, or, where workable,

That seems true for any IPsec connection, e.g., in 2401bis when the PAD
changes during a connection. I have been presuming 'connection latching'
- - where the PAD cannot change during a connection and where BTNS would
update the PAD once the connection is established.

Leap-of-faith addresses something different - where the PAD entries
persist between a series of connections, or are shared among connections
to the same endpoint.

Joe

---

From: hartmans-ietf at mit.edu (Sam Hartman)
Date: Tue, 06 Dec 2005 12:15:47 -0500

>>>>> "Joe" == Joe Touch <touch at ISI.EDU> writes:

    Joe> presuming 'connection latching' - where the PAD cannot change
    Joe> during a connection and where BTNS would update the PAD once
    Joe> the connection is established.

Joe, it's not quite that simple. Please take a look at the definition
of the PAD; it is quite complicated.  Also, propose a mechanism for
determining how long a connection exists.

Then propose updates to Nico's mechanism to support this once he posts
our notes.

I do believe there is a solution in there somewhere but I also believe
you are glossing over critical details necessary to make it actually
work.

---

From: touch at ISI.EDU (Joe Touch)
Date: Tue, 06 Dec 2005 09:24:01 -0800

> you are glossing over critical details necessary to make it actually

The details I'm glossing over are the ones I'm presuming exist for
conventional IPsec use.

Otherwise, what prevents the PAD from changing during a connection, and
the resulting authentication for an endpoint from being in flux?

If these details aren't already there, then there is certainly a large
amount of work to be done - but it is not BTNS-specific.

Joe

---

From: hartmans-ietf at mit.edu (Sam Hartman)
Date: Tue, 06 Dec 2005 12:30:50 -0500

>>>>> "Joe" == Joe Touch <touch at ISI.EDU> writes:

    Joe> Otherwise, what prevents the PAD from changing during a
    Joe> connection, and the resulting authentication for an endpoint
    Joe> from being in flux?

1) The PAD is assumed to be more or less static except under the
   control of the admin.

2) It *can* change and the authentication can be in flux.  This isn't
   really a problem for traditionnal IPsec.

--Sam

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Tue, 6 Dec 2005 11:32:04 -0600

> amount of work to be done - but it is not BTNS-specific.

The PAD isn't enough to perform a binding, I think, because it isn't a
requirement that PAD entries not overlap w.r.t. CHILD SA selector
constraints.

---

From: touch at ISI.EDU (Joe Touch)
Date: Tue, 06 Dec 2005 09:48:14 -0800

> 1) The PAD is assumed to be more or less static except under the

I didn't find any discussion of that in 2401bis. That seems like a
substantial security issue (as per below).

>    really a problem for traditionnal IPsec.

That would allow hijacking, just as with BTNS. An existing SA could
could be torn down or modified by an IKE authenticated in a different
way than the original SA.  That would then permit hijacking.

Joe

---

From: kent at bbn.com (Stephen Kent)
Date: Tue, 6 Dec 2005 12:51:55 -0500

>...
Joe,

The PAD was designed to fill a gap between the authorization data 
that IKE deals with, and the SPD, and to fill in gaps in the 
standards dealing with management of IKE authorization data. When I 
developed the PAD, in response to discussions in the pki4ipsec WG, 
nobody suggested that the PAD would be other than slowly changing. SA 
don't last forever, so if we assume a slowly changing PAD (very 
static in many contexts), then there was no need to worry about these 
issues. Hence no provisions were made to accommodate the implications 
of such changes on extant SAs.

Steve

---

From: touch at ISI.EDU (Joe Touch)
Date: Tue, 06 Dec 2005 10:10:55 -0800

Stephen Kent wrote:
> The PAD was designed to fill a gap between the authorization data that
> IKE deals with, and the SPD, and to fill in gaps in the standards
> dealing with management of IKE authorization data. When I developed the
> PAD, in response to discussions in the pki4ipsec WG, nobody suggested
> that the PAD would be other than slowly changing. SA don't last forever,
> so if we assume a slowly changing PAD (very static in many contexts),
> then there was no need to worry about these issues. Hence no provisions
> were made to accommodate the implications of such changes on extant SAs.
> 
> Steve

Hi, Steve,

While I understand an appreciate this, even 'slowly changing' allows for
change, and change allows a new entity with different authoriziation
credentials to affect active SAs.

Is it possible to copy the relevent PAD info used to authorize
establishment of the SA into the SA itself, so that such changes could
not be used maliciously?

Joe

---

From: kent at bbn.com (Stephen Kent)
Date: Wed, 7 Dec 2005 09:50:06 -0500

>requirement that PAD entries not overlap w.r.t. CHILD SA selector

Yes, that is a valid concern relative to the current spec.

When I suggested text (a few months ago) for a simple modification to 
the PAD to accommodate BTNS-style functionality, I believe I noted 
the requirement that PAD entries for BTNS peers must be checked to 
avoid overlap with both BTNS and non-BTNS peers. I may be able to 
find that text again, if needed.

Steve

---

From: kent at bbn.com (Stephen Kent)
Date: Wed, 7 Dec 2005 09:49:47 -0500

Joe,

>credentials to affect active SAs.

The 4301 (nee 2401bis) text does not say that the SAD or SPD-S cache 
should be searched and affected entries reverified when a PAD entry 
changes. This is in contrast to the SPD, where 4.4.1 notes that SPD 
changes SHOULD cause a recheck of active SAs and allow an admin to 
specify whether affected SAs should persist or be deleted.

In part the different is a result of the fact that changes to PAD 
entries can affect attributes of an IKE peer that need not have any 
effect on extant SAs. For example, if I change the IKE ID or the 
authentication credentials for a peer, or the gateway location info, 
that need not imply a need to recheck child SAs created relative to 
that peer. Only if the change is to the child SA ID/address 
constraints (relative to SPD matching) might it make sense to 
consider revalidation of extant SAs.

What if a new PAD entry is created? Because the PAD is ordered, it 
could be very complex to determine if a newly created entry affects 
extant SAs, or if it were even the intent of the change to affect 
them.

These considerations, plus the notion that the PAD is fairly static, 
caused us to not include text analogous to the SPD text in 4.4.1. 
Section 4.4.3.4 describes when the PAD is consulted. It is consulted 
during the initial IKE exchange, in support of IKE peer 
authentication and child SA constraints checking. It is also 
consulted during subsequent CREATE_CHILD_SA exchanges, for child SA 
constraints checking.

If an extant SA needs to be rekeyed, IKE is invoked to effect the 
rekey. The PAD should be checked as a side effect of creating a child 
SA, and because a rekey creates a new child SA, the (current) PAD 
should be checked at that time. So in that sense, a change to the 
PAD, in terms of a modification to a PAD entry, has an opportunity to 
affect an extant SA (when it is rekeyed).

There is some ambiguity here, in that the text does not say how to 
recheck the PAD for subsequent CREATE_CHILD_SA exchanges. If an 
implementation maintains a back pointer to the PAD from each IKE SA, 
and a back pointer to the IKE SA from each child SA, then rechecking 
the PAD for a rekey is easy. But what if the IKE SA has been deleted? 
The PAD is not designed to be searched based on traffic selectors for 
child SAs, but rather on IKE IDs.

I assume this is the sort of complexity that Sam had in mind when he 
said that use of a dynamic PAD requires a lot of thought.

>establishment of the SA into the SA itself, so that such changes could

Changes to the PAD are made by an authorized admin, just like changes 
to the SPD. So I don't think the term "malicious" applies here.

Steve

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Wed, 7 Dec 2005 08:54:08 -0600

> find that text again, if needed.

Keep in mind Joe's point that this is a problem for IPsec even without
BTNS in the picture.  A PAD entry that allows road warriors access to
dynamically allocated addresses will allow road warriors to steal each
other's traffic in the same way as we've discussed could happen with
BTNS.

Nico
--

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Wed, 7 Dec 2005 10:37:36 -0600

> other's traffic in the same way as we've discussed could happen with

Also, creating {IP, ID} bindings through a dynamic PAD is a DoS
attack vector and key rollover issues, as discussed at IETF64.

Addressing the DoS problem requires cooperation from other
infrastructure (e.g., DHCP servers) or idle timeouts (as discussed at
IETF64, but also through reference counts on binding PAD entries
representing references from outstanding connection-latched packet
flows, as discussed on the list recently).  Addressing the key rollover
issues requires KE extensions.

The Solaris connection latching approach seems like a trade-off by
creating such bindings only per-connection 5-tuples -- thus,
essentially, 7-tuples: {src IP, dst IP, src ID, dst ID, protocol, src
port, dst port} -- at the cost of possibly exposing applications that
use multiple connections between two peers.  (Bill surely will correct
me if I'm wrong.)

Nico
--

---

From: kent at bbn.com (Stephen Kent)
Date: Wed, 7 Dec 2005 17:05:51 -0500

>other's traffic in the same way as we've discussed could happen with

I don't think this discussion has provided a good example to 
illustrate the problem in question. I'm guessing that the concern 
begins with the notion that one needs to dynamically update or create 
a PAD entry to accommodate road warriors. However, there has been no 
discussion in IPsec to suggest that dynamic PAD entries are needed to 
support road warriors.

A PAD entry might identify the set of all road warriors for a company 
by a wild card name, e.g., [email-masked]. The authorization data for the 
entry might say that these individuals have certs that can be 
validated using the CA cert for BBN. The entry would also specify 
that the IKE ID (not the road warrior's source address) be used for 
SPD matching. The SPD entry for these folks would be tagged with the 
name.  Section 4.4.1.1 specifically gives the road warrior case as a 
motivation for the use of names to specify SPD entries, and says how 
to take the IP address of the road warrior (as the initiator) and use 
it as the remote address for the SPD entry (in a sort of PFP 
fashion). This should avoid the hijacking concern alluded to above.

Mike Richardson discussed how 2401 implementations (the PAD concept 
was not part of the old standard) supported road warriors, in the 
BTNS meeting at IETF64. Mike, how do you envision using a 
PAD-equipped IPsec to accommodate road warriors? Do you see a need 
for dynamic PAD entries?

Steve

---

From: hartmans-ietf at mit.edu (Sam Hartman)
Date: Wed, 07 Dec 2005 18:20:51 -0500

>>>>> "Stephen" == Stephen Kent <kent at bbn.com> writes:

    Stephen> A PAD entry might identify the set of all road warriors
    Stephen> for a company by a wild card name, e.g., [email-masked]. The
    Stephen> authorization data for the entry might say that these
    Stephen> individuals have certs that can be validated using the CA
    Stephen> cert for BBN. The entry would also specify that the IKE
    Stephen> ID (not the road warrior's source address) be used for
    Stephen> SPD matching. The SPD entry for these folks would be
    Stephen> tagged with the name.  Section 4.4.1.1 specifically gives
    Stephen> the road warrior case as a motivation for the use of
    Stephen> names to specify SPD entries, and says how to take the IP
    Stephen> address of the road warrior (as the initiator) and use it
    Stephen> as the remote address for the SPD entry (in a sort of PFP
    Stephen> fashion). This should avoid the hijacking concern alluded
    Stephen> to above.

It's exactly this situation that gives rise to the concern.

Think about what happens when two peers both identified by the same
PAD entry and both using the same name to select SPD entries (name
matching not IP matching) claim the same IP address.  What happens
when just as an SA expires a different peer claims the same remote IP
address?

---

From: kent at bbn.com (Stephen Kent)
Date: Thu, 8 Dec 2005 11:22:52 -0500

>when just as an SA expires a different peer claims the same remote IP

Sam,

You ask what happens if an SA (for a road warrior) expires and 
different peer claims the same remote IP address. It is not clear 
that there is any point in the re-key process that makes this a 
problem, per se. I think the real question is whether we check to 
ensure that we don't create two SAs with different peers but the same 
selector sets, when a child SA is created, in general. (Assume that 
the SAs in question have the remote ID address asserted by a road 
warrior, but the local IP address, protocol, and port fields are all 
ANY, a not-unreasonable SPD entry for such users.)

If we allowed such parallel, identical SAs (from a selector 
perspective) we have a serious problem in general, at least for 
SG/BITW implementations. This is because outbound traffic to either 
remote user from any host at the enterprise net would not be able to 
be mapped unambiguously to the right SA. So, I assume that a second 
user cannot have caused a new SA to be created with the same remote 
address as the first user, so long as an SA exists for the first 
remote user who asserted the address in question.

Note that 4301 (section 4.1) mandates support for multiple SAs with 
the same selectors between the SAME pair of IKE peers. The motivation 
for allowing multiple SAs between the same set of IKE peers is to 
allow use of different SAs for QoS, without making QoS an explicit 
selector value. This requirement was added because implementations 
often did not allow duplicate SAs to be created under any 
circumstances, and this was an explicit exception. So I think it is 
reasonable to assume that an IPsec implementation will not, in 
general, allow a second SA to be created with he same selector 
values, if the peer for the second SA is different from that of the 
extant SA.

To the best of my recollection, nobody ever raised the issue of 
allowing multiple SAs with the same set of selector values but 
terminating at different peers. One might imagine this would be a way 
to support load sharing or fast fail-over between one SG at one site 
and two of more SGs at a different site. If each peer is individually 
identified in the PAD, and thus presumed to be authorized for the 
same address space, then this would seem to be safe. However, if we 
create a PAD entry for a class of users, as in my road warrior 
example, and we don't want them to be able to assert overlapping 
ownership for the same address space (for obvious reasons), then we 
would want to prohibit creation of concurrent SAs with identical 
selector values, terminating at different peers. I think this 
behavior has been the default in most implementations, based on the 
discussions that led to the text in 4.1 (re support of multiple SAs 
for QoS support), although I admit that it is not clearly noted in 
the RFC.

Steve

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Thu, 8 Dec 2005 11:48:20 -0600

> ANY, a not-unreasonable SPD entry for such users.)

Now the real question is what happens at SA expiration time.

The same mechanism that you describe for protecting road warriors
can be used to protect BTNS nodes...

...but like BTNS the issue that comes up is: can an attacker sneak in by
preventing SA re-keying and then establishing a new SA with the attacker
instead of the victim as one end-point and with the same selectors as
the previous SAs.  If so, then IPsec has a problem.

Solutions based on persisting an {IP, ID} binding post-SA expiration
create problems of their own, as discussed at Vancouver and on the list
(how to know when to remove such a binding, dynamic address pool
exhaustion DoS attacks, key rollover in the BTNS case).

Solutions based on persisting a "7-tuple" (5-tuple + IDs) binding for
open connections (incuding BSD socket UDP "connections") create problems
for applications that use multiple connections between two peers.

Nico
--

---

From: touch at ISI.EDU (Joe Touch)
Date: Thu, 08 Dec 2005 08:59:53 -0800

Stephen Kent wrote:
> You ask what happens if an SA (for a road warrior) expires and different
> peer claims the same remote IP address. It is not clear that there is
> any point in the re-key process that makes this a problem, per se. I
> think the real question is whether we check to ensure that we don't
> create two SAs with different peers but the same selector sets, when a
> child SA is created, in general. (Assume that the SAs in question have
> the remote ID address asserted by a road warrior, but the local IP
> address, protocol, and port fields are all ANY, a not-unreasonable SPD
> entry for such users.)

How do you know they're different peers if they claim to be the same
peer and are authenticated differently? That seems to be what allows the
new peer to pose as the old one and affect even a persistent connection
to the old one (e.g., by rekeying).

Joe

---

From: kent at bbn.com (Stephen Kent)
Date: Thu, 8 Dec 2005 13:24:25 -0500

>the previous SAs.  If so, then IPsec has a problem.

If re-keying makes use of the IKE SA from which the child was 
created, then I don't think anyone else can "sneak in." if the IKE SA 
has been deleted, then we have an ambiguous case, because 4301, like 
2401, does not say how to locate an IKE peer when an outbound SA 
needs to be created.

>exhaustion DoS attacks, key rollover in the BTNS case).

I'd rather if we not transform "persist" into a transitive verb :-).

>for applications that use multiple connections between two peers.

Note that if the pair of peers (gee, that has a nice ring to it) is 
the same, multiple SAs are OK, and MUST be supported as per 4301, so 
this case ought not be a problem.

Steve

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Thu, 8 Dec 2005 14:08:30 -0600

> 2401, does not say how to locate an IKE peer when an outbound SA 

This does not address DoS attacks aimed at preventing re-keying.

> I'd rather if we not transform "persist" into a transitive verb :-).

Sigh.

Nico
--

---

From: hartmans-ietf at mit.edu (Sam Hartman)
Date: Thu, 08 Dec 2005 17:48:17 -0500

>>>>> "Stephen" == Stephen Kent <kent at bbn.com> writes:

    Stephen> The rest of the paragraph just said that we don't specify
    Stephen> how to locate an IKE peer when creating an IKE SA in
    Stephen> general. It seems hard to characterize the DoS
    Stephen> vulnerability of an unspecified mechanism.

I don't think outbound SAs are where we should be focusing our
thoughts.  If I'm going to try and attack this mechanism I'm going to
try and cause dead peer detection to delete the SA or prevent rekey of
the IKE SA.  Then I'm going to try and initiate an IKE SA of my own
and create child SAs that are interesting.  I don't see how the
outbound peer selection matters.  Once child SAs are created, IKE is
no longer involved.

---

From: kent at bbn.com (Stephen Kent)
Date: Thu, 8 Dec 2005 15:59:08 -0500

>This does not address DoS attacks aimed at preventing re-keying.

To what part of the paragraph you cited does this observation apply?

It would seem that use of an existing IKE SA for re-key is as 
resistant to a DoS attack as any IKE SA after it is established.

The rest of the paragraph just said that we don't specify how to 
locate an IKE peer when creating an IKE SA in general. It seems hard 
to characterize the DoS vulnerability of an unspecified mechanism.

Steve

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Thu, 8 Dec 2005 16:50:24 -0600

> To what part of the paragraph you cited does this observation apply?

The first sentence.

> resistant to a DoS attack as any IKE SA after it is established.

But if IKE traffic can't get through the SA will eventually expire...

> to characterize the DoS vulnerability of an unspecified mechanism.

Right, I was referring to the first part.  I thought that would be clear.

Nico
--

---

From: kent at bbn.com (Stephen Kent)
Date: Thu, 8 Dec 2005 18:28:55 -0500

>outbound peer selection matters.  Once child SAs are created, IKE is

I noted outbound SA creation because the SG might be the peer that 
would try to initiate the re-key, if the timer or traffic volume 
triggers fire there first.

If the re-key trigger occurs at the road warrior, it can use the 
(parent) IKE SA for re-key and we are just as secure as what I noted.

it is not true that the IKE SA is not relevant after a child SA is 
created. Additional CREATE_CHILD_SA payloads are sent over the IKE 
SA, and thus that SA can be used for re-key, without the overhead of 
a a new IKE SA being created.

Steve

---

From: kent at bbn.com (Stephen Kent)
Date: Thu, 8 Dec 2005 17:22:20 -0500

>to the old one (e.g., by rekeying).

In this example the peers assert different IDs and these IDs are 
verified based on use of different credentials, even though they are 
authenticated under a single PAD entry. So, they are not claiming to 
be the same entity at the peer authentication stage of the process. 
Both the original peer and the new peer map to the same SPD entry, if 
we use a wild card name there (not because of use of the wild card 
name in the PAD entry). Thus the new peer is free to assert the same 
remote IP address as the previous peer, based only on the SPD check. 
If we retain the peer ID from the previous entity (as part of the 
SPD-S cache entry), that could be used to reject attempts to assert 
the same remote address by a new entity, and still allow a remote 
entity to initiate a re-key while retaining an existing, remote 
address. But, let's look first at why this has not been an issue to 
date.

If the (parent) IKE SA is still present, then by using that SA to 
protect the re-key we ensure that the peer for the re-key is 
unchanged. So, persistence of that SA is a simple, secure solution to 
this problem. It's also preferable from a performance perspective, as 
we avoid the need to perform a new DH operation or  re-authenticate 
the peer.

Although Mike has not yet responded to this thread,I believe many 
IPsec SG implementations assign an address to the road warrior, from 
a pool reserved for road warriors, rather than allowing the RW to 
assert its address. The notion is that outbound traffic to RWs has to 
be routed to the SG, and thus a pool of addresses is reserved for 
this purpose. This prevents a new IKE exchange from resulting in a 
remote address that is already in use, although it also would pull 
the address put from under a RW who was re-keying a long-lived SA, 
and thus kill extant connections using the old SA.

My guess is that the problem we have been discussing is not a problem 
in practice.  Use of the (parent) IKE SA, if it exists, avoids the 
problem. If that SA is not available, use of the DHCP-style address 
assignment by an SG avoids the hijacking concern, although at the 
expense of connection continuity. Given likely SA durations based  on 
crypto security criteria, it seems unlikely that re-keying will be 
needed for most RWs. My experience as a RW is that my hotel usually 
time out my DHCP lease and cause me to reconnect if I linger too long 
reading e-mail.

We could add the peer IKE ID to the SPD-S cache part of the 4301 
processing model in a future document if folks agree that it is 
needed, and if it helps address the concerns raised by proposed BTNS 
use of PAD.

Steve

---

From: kent at bbn.com (Stephen Kent)
Date: Thu, 8 Dec 2005 18:40:18 -0500

>Right, I was referring to the first part.  I thought that would be clear.

Thanks for the clarification, but I'm still not certain I understand 
your point. Are you suggesting that  an attacker will
	- wait for a child SA to timeout (or come close to timeout)
	- suppress traffic between the road warrior and the SG, on 
the IKE SA to prevent its use for rekey
	- wait for that SA to time out
	- and then try to initiate a new IKE SA so that the attacker 
(who has the credentials of another valid RW user) can pose as the 
road warrior whose IKE SA and child SAs both timed out?

The goal of this attack is to take over connections to hosts behind 
the SG, where these connections belong to the first RW (assuming that 
these connections have not themselves timed out by now)?

Sorry, but I think your comment was way too brief for me to reliably 
infer all of that context. I would not say that this attack can't be 
carried out, but it requires enough timeouts and active wiretapping 
events as to be pretty far down on the list of things to worry about, 
in my opinion.

Steve

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Thu, 8 Dec 2005 18:25:14 -0600

> road warrior whose IKE SA and child SAs both timed out?

Yes.

> these connections have not themselves timed out by now)?

(Not just tunnels...)

Relying on connection timeouts being significantly smaller than SA
timeouts seems unlikely to work (particularly if said timeouts have to
be enforced by nodes behind an SG that have no idea that they have to do
this).

> events as to be pretty far down on the list of things to worry about, 

I'm not so sure.  I'm thinking of wifi scenarios and social engineering.

For example, suppressing traffic between a road warrior and its peers
may seem difficult, but if the attacker can get the victim to move out
of range of its AP(s) then the attacker has effectively suppressed
traffic between the victim and its peers.  No active wire tapping is
needed in such a scenario.  Come on, get with the program: it's all
about wireless nowadays, especially for road warriors!  :)

In any case, something concrete does result from this discussion: if we
can specify BTNS such that BTNS nodes get the same level of protection
that road warriors get in 4301 then we can declare concerns about
attacks like the above out of scope for the base BTNS spec.

Nico
--

---

From: hartmans-ietf at mit.edu (Sam Hartman)
Date: Thu, 08 Dec 2005 21:37:46 -0500

>> thoughts.  If I'm going to try and attack this mechanism I'm
    >> going to try and cause dead peer detection to delete the SA or
    >> prevent rekey of the IKE SA.  Then I'm going to try and
    >> initiate an IKE SA of my own and create child SAs that are
    >> interesting.  I don't see how the outbound peer selection
    >> matters.  Once child SAs are created, IKE is no longer
    >> involved.

    Stephen> I noted outbound SA creation because the SG might be the
    Stephen> peer that would try to initiate the re-key, if the timer
    Stephen> or traffic volume triggers fire there first.

    Stephen> If the re-key trigger occurs at the road warrior, it can
    Stephen> use the (parent) IKE SA for re-key and we are just as
    Stephen> secure as what I noted.

Again, we are talking about rekey of the IKE SA, not rekey of the
child SAs.  I agree with you that if the IKE SA is still alive that
there is an obvious secure behavior to implement: do not let child SAs
from one peer replace child SAs from another peer.

    Stephen> it is not true that the IKE SA is not relevant after a

Sorry, what I meant hear is that IKE and thus the peer selection
algorithm are not important for the lifetime of a particular child SA
once that child SA is created.  The IKE process is only invoked to
create new SAs; traffic will flow over existing SAs without
involvement of IKE.  If an attacker can create a situation where only
the attackers' child SAs exist, then for the life of those SAs,
traffic selected by the SPD will flow over those SAs.

--Sam

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Thu, 8 Dec 2005 22:35:36 -0600

> attacks like the above out of scope for the base BTNS spec.

Or maybe not.  The threat models for road warriors talking to SGs and
for BTNS nodes doing end-to-end IPsec need not be the same.

---

From: kent at bbn.com (Stephen Kent)
Date: Fri, 9 Dec 2005 09:17:11 -0500

Nico,

I too think this has been a useful discussion, although it would be 
easier (at least for me) if we had articulated the precise 
description of the potential problem from the beginning :-).

I agree that we ought not rely on the relative timeout durations for 
user connections vs. SAs. However, I do believe that the former are 
generally much shorter than the latter. From a crypto perspective, at 
typical RW access speeds, it would take many hours to send enough 
traffic to warrant a re-key of a child SA, even using 32-bit sequence 
numbers. Now that we have mandated support for 64-bit sequence 
numbers for these SAs, basic crypto concerns are not likely to ever 
trigger a re-key. The peer node is likely to crash before it triggers 
a re-key based on traffic volume.  Thus we have to ask what 
time-based re-key interval is appropriate, for other than crypto 
reasons. The same question applies to IKE SAs. They carry so little 
traffic that basic crypto concerns are also not likely to ever 
trigger a re-key. Since retaining these SAs offers great benefits 
with regard to creating new child SAs, and for SA maintenance in 
general, I would guess the primary reason to delete them is if an 
implementation runs out of space for the SA state.

Your wireless access example is a valid one, although I would argue 
that the list of attacker actions that needs to be exercised to 
execute the attack is getting pretty long ;-).

Your closing comment seems a little bit ambiguous. We have identified 
residual vulnerabilities for RW use of (vanilla) IPsec, given a 
specific set of assumptions about how one choose to define PAD and 
SPD entries. There are other options for PAD and SPD configuration 
ton accommodate RWs, which would be more secure but more onerous from 
a management perspective. It seems fair to say that if BTNS is used 
in a context where RWs are supported as I described, then it need not 
be more secure than vanilla IPsec, to meet the criterion established 
by Sam when the WG was chartered. But, an IPsec context that does not 
support RWs, or that uses a different PAD & SPD configuration 
approach to accommodate them ought not be made more vulnerable by 
BTNS use, right?

Steve

---

From: kent at bbn.com (Stephen Kent)
Date: Fri, 9 Dec 2005 09:40:12 -0500

>for BTNS nodes doing end-to-end IPsec need not be the same.

Agreed.

Steve

---

From: kent at bbn.com (Stephen Kent)
Date: Fri, 9 Dec 2005 09:39:41 -0500

Agreed.

>traffic selected by the SPD will flow over those SAs.

Agreed, but in order for the attacker to cause his SA to replace the 
SA in question, the attacker has to go through the SA creation 
process. I was just exploring both sides of that process, for 
completeness.

I also was noting that, in practice, there are a number of parameters 
in the system that have to align just right to allow peer-B to create 
an SA that replaces the SA of peer-A, in the example context we are 
discussing.

Note that this problem could, in principle, arise in other cases, not 
just for road warriors. Thne heart of the vulnerability is that we 
allow wild card PAD and SPD entries, an essential feature to make 
access control manageable. If two (or more) peers identified in the 
PAD have child SA constraints that overlap in name spaces or address 
space, then it is always possible for different peers to establish 
SAs that, at least serially in time, employ the same selector sets. A 
vendor could offer a PAD/SPD checker utility to alert admins to this 
potential problem, to help avoid configuration errors that create 
this situation unintentionally (as opposed to as a side effect of 
what the admin considers to be a reasonable way to configure the 
databases).

The inclusion of the peer ID in the SPD-S would prevent the hijacking 
concern in the case of a re-key when the corresponding IKE SA is not 
available, but it would not address the time serial problem noted 
above, since in that case the old SA might have been deleted. In that 
case we are again left with the possibility, noted by Nico, that the 
user's connection timeout is long enough to allow the connection to 
persist beyond the SA lifetime.  In a native host implementation this 
problem might be more addressed in other ways, but for an SG or BITW 
implementation ...

Steve

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Fri, 9 Dec 2005 09:49:55 -0600

> >for BTNS nodes doing end-to-end IPsec need not be the same.

In particular, I suspect that road warriors doing VPN aren't too
concerned about their peer road warriors for in all likelihood the
network behing the SG is not very secure to begin with and it would be
easier for an authorized user to go to a physical office, jack in to the
LAN and attack from there.

I think this attack is much more worrisome on end-to-end situations,
where IPsec may be the only session protection available to some
applications.  What saves 4301 in this case may simply be [speculation
ahead] that noone uses end-to-end IPsec in very dynamic environments.

BTNS is not intended (by most of us here, I think) to be used for
talking to SGs, but for end-to-end IPsec -- BITS and native modes.

The same attack that may not bother road warriors talking to SGs seems
definitely more worrisome to me for BTNS.

So perhaps we do have a duty to address the problem.

Nico
--

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Fri, 9 Dec 2005 10:00:07 -0600

> description of the potential problem from the beginning :-).

There you go again :)

> trigger a re-key.

Well, it's not just the 64-bit sequence numbers, but the use of 128-bit
block ciphers.

At any rate, why should mobile nodes negotiate very long-lived SAs?  Or,
more importantly, why should their peers allow them to negotiate very
long-lived SAs?  (And how can a node, not an SG, know that a peer is
mobile?)

> execute the attack is getting pretty long ;-).

Nah, just get the victim out of range with some good excuse and keep
them out for as long as it takes for the victim's SAs to expire, then
take over the victim's IP address and slide in.  The attacker has to
have credentials that match the same PAD entry or a similar one to that
matched by the victim on the target SG -- a pretty strong requirement,
but one that is easy to meet if the victim was a BTNS node!

> approach to accommodate them ought not be made more vulnerable by 

Right, I corrected myself subsequently -- the same attack can be of
different value in different contexts because we'll have different
threat models.  OTOH, a solution to this attack should be general, even
if specifically needed by BTNS.

But note that the RW issue is not just for RWs -- RW may be the primary
example for the use of wildcards in 4301, but certainly I could see
folks using those in contexts other than RWs talking to SGs.

Nico
--

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Fri, 9 Dec 2005 10:05:44 -0600

> problem might be more addressed in other ways, but for an SG or BITW 

Yes, it's difficult to see a solution for SGs or BITW -- they're too far
removed from the actual applications to know whethere packet flows are
outstanding.  Of course, they could watch TCP (and SCTP) traffic and
apply the kinds of heuristics that NAT boxes do, with the same degree of
satisfaction, no doubt.

Native mode can do much better -- by cooperating with the ULPs (which in
turn cooperate with the applications), native IPsec can know exactly
when said flows are active or gone.  Connection latching takes advantage
of this.

Nico
--

---

From: kent at bbn.com (Stephen Kent)
Date: Fri, 9 Dec 2005 11:39:08 -0500

Nico,

I agree that IPsec probably is not used very often for end-to-end 
security, because most enterprise nets don't like to allow 
network-layer encrypted traffic through firewalls. (This problem will 
not go away because of BTNS.)

For end systems it makes sense to see if there are was to take 
advantage of the additional connection state knowledge available to 
help address these concerns.

Steve

---

From: kent at bbn.com (Stephen Kent)
Date: Fri, 9 Dec 2005 11:50:52 -0500

>Well, it's not just the 64-bit sequence numbers, but the use of 128-bit

128-bit block ciphers are good for VERY large traffic volumes, about 
2**64 blocks, and 16 bytes per block) is a lot of data. It was use of 
DES, a 64-bit block cipher, that made this more of a concern, but 
even then most SAs were not in place long enough for this to be an 
issue.

>long-lived SAs?  (And how can a node, not an SG, know that a peer is

Two answers:
	- first, this is not so much a mobile vs. stationary user 
matter. with AES-128 and 64-bit sequence numbers, it should be very 
rare for an SA to persist long enough to need to be re-keyed for 
crypto reasons.
	- second, why negotiate a short lived SA, and incur the cost 
and complexity of re-keying if you don't have to?

>but one that is easy to meet if the victim was a BTNS node!

For the last few days we were having a discussion about whether BTNS 
might create new security problems as we modified the PAD to 
accommodate BTNS functionality, or whether we already had serious 
security problems in the vanilla IPsec context. Your example 
illustrates how support for BTNS might cause what was a low risk 
residual vulnerability in vanilla IPsec into a more serious concerns 
in a BTNS context.

>folks using those in contexts other than RWs talking to SGs.

Yes, wild cards are not restricted to RW scenarios.

Steve

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Fri, 9 Dec 2005 13:32:36 -0600

> even then most SAs were not in place long enough for this to be an 

That's what I said -- you say that because of 64-bit sequence numbers
SA expiration is not driven by traffic volume, and I added that 128-bit
cipher block sizes are necessary also for traffic volume to be a
non-issue.

Nico
--

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Fri, 9 Dec 2005 13:35:19 -0600

> and complexity of re-keying if you don't have to?

But then you have to do dead peer detection when IP addresses are
re-assigned.

Look, a road warrior with a 30 minute DHCP lease ought not be
negotiating SAs that live longer than the DHCP lease.  Else the next
road warrior to take that address (and talk to the same peers as the
first) will be unhappy.

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Fri, 9 Dec 2005 13:49:43 -0600

> not go away because of BTNS.)

But even inside intranets I suspect end-to-end use of IPsec is not
widespread.  I think the problem we've been discussing is more serious
for end-to-end uses of IPsec than for VPN uses of it, and that since
BTNS is intended to be used in end-to-end fashion this problem is more
serious for BTNS specifically than for VPN.

> help address these concerns.

Right.  Connection latching does exactly that.

We need to think about how to describe connection latching in RFC4301
terms and what extensions RFC4301 might need for connection latching.

Similarly for leap-of-faith, if anyone still thinks we need it.

---

From: kent at bbn.com (Stephen Kent)
Date: Fri, 9 Dec 2005 14:59:10 -0500

>cipher block sizes are necessary also for traffic volume to be a

Sorry, I misunderstood your comment.

Steve

---

From: kent at bbn.com (Stephen Kent)
Date: Fri, 9 Dec 2005 15:02:30 -0500

>But then you have to do dead peer detection when IP addresses are

yes, but DPD is a function that most vendors consider important, for 
a variety of reasons.

>road warrior to take that address (and talk to the same peers as the

I see your point. I was thinking about tunnel mode, since that is 
what one uses to contact an SG, and it the change in the outer IP 
address need not affect the SA, as the MOBIKE folks have described in 
detail in their documents.  Maybe that's (another) good reason to use 
tunnel mode in contexts like this.

Steve

---

From: kent at bbn.com (Stephen Kent)
Date: Fri, 9 Dec 2005 15:04:33 -0500

>serious for BTNS specifically than for VPN.

Yes, it's probably fair to say that the configuration management 
required for access control and for authentication deter intra-net 
use of IPsec.

>Similarly for leap-of-faith, if anyone still thinks we need it.

OK.

Steve

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Fri, 9 Dec 2005 14:08:58 -0600

> required for access control and for authentication deter intra-net 

On the other hand, adding features such as connection latching that
provide protection against hijacking would make configuration of
end-to-end IPsec simpler by allowing the safe use of PAD entries with
wildcards for ID matching and large IP address ranges for selector
constraints.

Nico
--

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Fri, 9 Dec 2005 14:13:10 -0600

> yes, but DPD is a function that most vendors consider important, for 

You once again misunderstood my point, which was not to cast aspertions
on DPD.  See below.

> tunnel mode in contexts like this.

The point is that relying on SA expiration to add protection against the
highjacking problem doesn't help if DPD is used and, OTOH, if DPD is not
used then long SA expiration can lead to dynamic address exhaustion (a
DoS).

Nico
--

---

From: kent at bbn.com (Stephen Kent)
Date: Fri, 9 Dec 2005 15:49:57 -0500

>used then long SA expiration can lead to dynamic address exhaustion (a

When I misread your comment on 128-bit block ciphers the error was 
all mine. I read the sentence too quickly. However, the text above is 
not as clear as it could be.

You refer to "relying on SA expiration" without indicating whether 
you are referring to long duration SAs or short duration SAs. Do you 
mean that we can have shorter duration SAs and re-key them safely IF 
we keep around the IKE SAs, via which we perform DPD?

Yes, longer duration SAs, without DPD, create a DoS potential, but 
this seems to be mostly a BTNS issue, since otherwise the ability to 
create an SA is strictly limited to (pre-) authorized peers.

Steve

Steve

---

From: kent at bbn.com (Stephen Kent)
Date: Fri, 9 Dec 2005 15:59:49 -0500

>wildcards for ID matching and large IP address ranges for selector

maybe. it really depending on how one is using IPsec, the user 
population (RWs vs. satellite offices vs. inter-enterprise VPNs, 
...), etc.

your actual configuration savings may vary ...

Steve

---

From: pekka.nikander at nomadiclab.com (Pekka Nikander)
Date: Thu, 15 Dec 2005 11:15:58 +0100

Steve,

> tunnel mode in contexts like this.

FWIW, I think there is a deeper architectural issue lurking in here.

Using tunnel mode (especially with rfc 1918 addresses) implements a  
kind of identifier/locator split.  The inner addresses are no more  
used as locators (at least in the Internet) but more as identifier  
proxies, to tie security semantics to something that exists at the IP  
layer.  The outer addresses act as locators, at least at the Internet  
side.

Of course, the distinction is not clear, as the inner addresses are  
likely to be used as both identifier proxies and locators in the  
intranet side.

 From this point of view, I fully agree with you: using tunnel mode  
have good reasons here.  However, I also think that in the long run  
we should go forward, and try to get rid of tunnel mode overhead by  
implementing the required id/loc split directly at the host level.

Given the direction BTNS seems to be taking, i.e., using public keys  
a identifiers, this mostly becomes an API  issue.  That is, how do we  
represent the public keys to the applications.  Do we use inner IP  
addresses as proxies for them, as we do today?  If so, should we  
perhaps recommend use CGA or KHI addresses and only IPv6 API, to  
provide some intrinsic security to the binding between the inner  
addresses and the identifiers?  Or should we have a completely new  
API, allowing applications to learn the IP addresses the public key  
through the new API?  Finally, if we use this kind of id/loc-split- 
like tunnel mode in end-to-end BTNS, should we perhaps go for tunnel  
overhead reduction?  (I think MOBIKE is considering doing that.)

[KHIs are defined in draft-laganier-ipv6-khi-00.txt]

 From my very personal point of view, I would like to see the whole  
stack architecture to evolve to a direction where we use KHI  
addresses as "inner addresses" or identifiers, tunnel them to outer  
addresses or locators locally at the end-node, and reduce the  
tunnelling overhead to minimum.  The problem with this approach, of  
course, is the initial resolution from KHI addresses to the locators.

 From my point of view, that would provide fairly good backwards  
compatibility with applications using IPv6 addresses.  The transport  
efficiency (header overhead) would be minimal.  And it would provide  
applications with IP addresses that have security semantics similar  
to what IPsec expects today but independent of the usage, lifetime,  
and selection of the outer addresses.

--Pekka

---

From: kent at bbn.com (Stephen Kent)
Date: Thu, 15 Dec 2005 09:47:14 -0500

Pekka,

Gee, are we getting cross talk from the HIP WG list :-)?

Seriously, the inner/outer header address processing differences in 
tunnel mode are not motivated by the features you described. The 
inner address is used as the locator and ID by both the sender and 
the (ultimate) receiver. The outer header is applied to direct the 
packet to a specific SG, to address problems that could arise if 
there are multiple SGs, if fragmentation occurs, etc. By convention 
we require use of tunnel mode for both SAs in a pair,to make life 
simpler.

>a identifiers, this mostly becomes an API  issue.  That is, how do 
>we represent the public keys to the applications.  Do we use inner 
>IP addresses as proxies for them, as we do today?  If so, should we 
>through the new API?  Finally, if we use this kind of 
>id/loc-split-like tunnel mode in end-to-end BTNS, should we perhaps 
>go for tunnel overhead reduction?  (I think MOBIKE is considering 
>doing that.)

This argument seems to be very host-implementation centric. IPsec is 
used in host, BITW and SG contexts.  Maybe BTNS needs to decide 
explicitly whether it is targeted only at hosts, or also at BITW and 
SG contexts, before we consider arguments that are host-centric.

Steve

---

From: pekka.nikander at nomadiclab.com (Pekka Nikander)
Date: Fri, 16 Dec 2005 06:59:42 +0100

Steve,

> Gee, are we getting cross talk from the HIP WG list :-)?

You know, from the very beginning one of the reasons why I agreed to  
co-chair this WG was due to my personal believe that BTNS would be a  
step to the "right" direction.  Whether HIP is the right direction or  
not, not even the jury is out yet but we are still collecting  
evidence.  However, personally, I believe that there are multiple  
reasons why we will need a new layer of indirection in the stack.   
Given that, I've been quite convinced for a number of years now that  
the "right" place to add such indirection is at the boundary between  
the end-to-end and hop-by-hop functions at the IP layer.  IPsec  
happens to be just there, for good reasons.

> we require use of tunnel mode for both SAs in a pair,to make life  

I am not arguing about the conventional use of tunnelling.  Like you  
are (rightly) labelling my argumentation as host centric, I'd be  
tempted to label your argumentation as VPN centric.  FWIW, I find it  
still quite sad that the IPsec WG took the VPN oriented direction for  
so many years and almost ignored host-centric possibilities.  But I  
think I do understand many of the reasons for that, though not  
necessarily all.

Given that, I'd allude that you are above, intentionally or not,  
ignoring the sore reality that SGs are often (but not always) placed  
at the boundary between RFC 1918 addressed and publicly addressed  
network segments.  When used in such a way, SGs and tunnelling as  
used for what some people call "IP virtualisation".  I don't know if  
you have followed the recent discussions at the INT area and  
architecture-discuss mailing lists, but I've been questioning there  
whether such "IP virtualisation" is a sound long-term practise or  
more an indication of something missing from the networking service  
that we provide.  (As a shorter-term practice IP virtualisation or  
VPNs are a fine too, no problem with that.)

Hence, while you are certainly right stating that when the tunnel  
processing model was designed people did not necessarily consider the  
processing differences in terms of id/loc split, I still find it  
interesting that there are so many parallels between the current  
operational reality and the requirements that are leading to me to  
believe that there is a need of a new indirection layer.

>> Given the direction BTNS seems to be taking, i.e., using public  
>> keys a identifiers, this mostly becomes an API  issue.  That is,  
>> how do we represent the public keys to the applications.  Do we  
>> use inner IP addresses as proxies for them, as we do today?  If  
>> so, should we perhaps recommend use CGA or KHI addresses and only  
>> IPv6 API, to provide some intrinsic security to the binding  
>> between the inner addresses and the identifiers?  Or should we  
>> have a completely new API, allowing applications to learn the IP  
>> addresses the public key through the new API?  Finally, if we use  
>> this kind of id/loc-split-like tunnel mode in end-to-end BTNS,  
>> should we perhaps go for tunnel overhead reduction?  (I think  
>> MOBIKE is considering doing that.)
>
> This argument seems to be very host-implementation centric.

Indeed.

> IPsec is used in host, BITW and SG contexts.  Maybe BTNS needs to  
> decide explicitly whether it is targeted only at hosts, or also at  
> BITW and SG contexts, before we consider arguments that are host- 
> centric.

Personally, I don't believe that all solutions BTNS produces must  
work equally in the host, BITW and SG contexts.  That is, I'm fine if  
the use of BTNS is more limited if used in BITW and/or SG contexts  
than when used in a pure host-to-host implementation context.  But  
that is up to the WG to decide.

But there seems to be a quite few issues here:

- Quite a lot of the current discussion (connection latching, SPD/SA  
hijacking etc) seems to be intrinsically related to the underlying  
provisioning model.  Indeed, the main difference between BTNS and  
"traditional" IPsec is in the provisioning models.  In traditional  
IPsec, explicit configuration is a cornerstone for security while  
BTNS aims for a weaker security model where little or no  
configuration and no explicit credentials provisioning are needed.

- The harder part in any tunnelling (IPsec or not) is provisioning or  
configuration.

- From an end-point / stack architecture point of view, the  
difference between tunnelling and address-preserving double address  
translation is a very fine one.  Almost non-existing.   Tunnelling  
changes the IP addresses the network sees by wrapping an existing  
packet within a new header.  As a packet emerges from the tunnel, it  
has the same IP addresses as before entering.  Double address  
translation changes the IP addresses the network sees by replacing  
the IP addresses in the packet.  After the "unwrapping" translation  
at the receiver end, the packet has the same IP addresses as before  
getting translated.  The biggest practical or provisional difference  
is that double translation requires that there is one-to-one mapping  
between <inner-src, inner-dst> and <outer-src, outer-dst, spi> pairs  
while tunnelling doesn't.

So, trying to put the argumentation above together, my tentative  
conclusions are the following:

1. I see there definitive architectural value in solutions that  
advance the stack architecture into a direction where we implement a  
new layer of indirection (roughly) at the same place where IPsec is.

2. We need to be very careful when we think about the BTNS  
provisioning model and its consequences to security.

3. One potential way to solve/avoid problems related to connection  
latching and leap-of-faith is to make changes at the API level.  One  
possible way to change the API is to provide applications with  
identifiers that fulfil their current semantic assumptions but that  
are not used as locators in the network.  Such usage is, the  
provisioning model disregarding, fairly close to some current uses of  
IPsec tunnelling.

I admit that this is a complex issue and requires, at least for me,  
some mind-boggling shifts in viewpoints while thinking through.

--Pekka

---

From: touch at ISI.EDU (Joe Touch)
Date: Fri, 16 Dec 2005 11:02:34 -0800

> layer.  The outer addresses act as locators, at least at the Internet  

I disagree; the outer addresses locate the decapsulating security
device, but the inner addresses still just locate the endpoint from that
point on. They're not global address/locators, but local to the SG-host
path, and they still combine name and location, as you note below.

> have good reasons here.

Tunnels can be used several ways:
	1- keep the SA but allow outer addresses to change
	2- keep the SA but allow inner addresses to change
	3- make the SA inner + outer specific

All three modes have their uses; 3 is certainly more conservative, but 1
is needed for mobility without rekeying and 2 is needed (and typically
used) for aggregation (e.g., VPN for a subnet).

There are a lot of subtle issues that evolve out of that, as you note
with respect to efficiency, but also with respect to dynamic routing,
etc. BTNS may provide an opportunity for some of this as follow-on, but
seems out of scope at this time, IMO.

Joe

---

From: touch at ISI.EDU (Joe Touch)
Date: Fri, 16 Dec 2005 11:10:46 -0800

> provisioning model and its consequences to security.

I'm wondering if we can address the persistent concerns about BTNS
creating new holes by saying simply and directly:

"BTNS is intended to protect BYPASS'd traffic from off-path attacks."

(i.e., SPD entries that the administrator would be just as comfortable
setting as BYPASS).

?? (I appreciate this may be too direct or too simplistic, but I wonder
if it helps)...

Joe

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Fri, 16 Dec 2005 13:28:50 -0600

> "BTNS is intended to protect BYPASS'd traffic from off-path attacks."

No, because as we discussed a week or so ago the applicability statement
says that BTNS protects against on-path MITM attacks subsequent to
initial exchanges.

What you may want to propose is that we drop that requirement.

---

From: touch at ISI.EDU (Joe Touch)
Date: Fri, 16 Dec 2005 11:47:08 -0800

> What you may want to propose is that we drop that requirement.

I'm proposing that you don't use BTNS unless you would have been
comfortable using BYPASS on that traffic; I'm not proposing that it's
identical.

Joe

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Fri, 16 Dec 2005 13:50:35 -0600

> comfortable using BYPASS on that traffic; I'm not proposing that it's

I don't understand -- what is not identical to what?

Please address the on-path MITM issue.

---

From: touch at ISI.EDU (Joe Touch)
Date: Fri, 16 Dec 2005 13:14:27 -0800

> I don't understand -- what is not identical to what?

BTNS != BYPASS

> Please address the on-path MITM issue.

If you restrict the use of BTNS to traffic that you could have been
comfortable BYPASSing, MITM is moot.

Joe

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Fri, 16 Dec 2005 15:47:19 -0600

> comfortable BYPASSing, MITM is moot.

So are we then to understand that you do want to drop protection-
against-MITM-attacks-after-initial-key-exchange from the requirements
for BTNS?

---

From: touch at ISI.EDU (Joe Touch)
Date: Fri, 16 Dec 2005 14:51:11 -0800

> against-MITM-attacks-after-initial-key-exchange from the requirements

No - but since you don't know who you're doing the initial key exchange
with, you shouldn't do such exchanges with any party you wouldn't
basically be willing to do BYPASS with.

Joe

---

From: kent at bbn.com (Stephen Kent)
Date: Fri, 16 Dec 2005 18:48:55 -0500

At 6:59 AM +0100 12/16/05, Pekka Nikander wrote:

>step to the "right" direction.

The charter of BTNS focuses on contexts in which not authenticating a 
peer at the IP layer is a useful feature. It does not discuss the 
locator/ID separation that is the gist of your previous message.

>   Whether HIP is the right direction or not, not even the jury is 
>out yet but we are still collecting evidence.  However, personally, 
>I believe that there are multiple reasons why we will need a new 
>layer of indirection in the stack.

As noted above, I think this WG is not an appropriate place to have 
this discussion, given its charter.

>still quite sad that the IPsec WG took the VPN oriented direction 
>for so many years and almost ignored host-centric possibilities. 
>But I think I do understand many of the reasons for that, though not 
>necessarily all.

I disagree with your characterization. I think IPsec adopted a 
perspective that encompassed host, BITW, and SG approaches to 
providing the set of securty services we aim to provide.

>VPNs are a fine too, no problem with that.)

I have not followed those discussions.  But I don't think this WG is 
an appropriate place to pursue them, given the charter.

>processing model was designed people did not necessarily consider 
>the processing differences in terms of id/loc split, I still find it 

You may be right, but again, I would argue that the creation of the 
indirection layer option is a HIP WG matter, not a BTNS matter.

>>BITW and SG contexts, before we consider arguments that are 
>>host-centric.
>
>work equally in the host, BITW and SG contexts.  That is, I'm fine 
>if the use of BTNS is more limited if used in BITW and/or SG 
>contexts than when used in a pure host-to-host implementation 
>context.  But that is up to the WG to decide.

agreed.

>configuration and no explicit credentials provisioning are needed.

I would say that BTNS is motivated by the perception that 
provisioning for authentication is a burden in many contexts and that 
there are situations where it makes sense to avoid this burden.

>- The harder part in any tunnelling (IPsec or not) is provisioning 
>or configuration.

oh?

>while tunnelling doesn't.

One can perform tunneling for different reasons, some (many?) of 
which are distinct from the reasons for address translation. As I 
noted previously, tunneling for IPsec is motivated (in large part) by 
the need to direct the traffic to a specific SG, to ensure that the 
traffic arrives at a point where the SA state is present. if one 
reads more into tunneling than that, one is going outside the intent 
of the IPsec WG efforts.

>new layer of indirection (roughly) at the same place where IPsec is.

Which is what HIP is doing, right? So why should this be part of the 
discussion here?

>provisioning model and its consequences to security.

no argument there.

>provisioning model disregarding, fairly close to some current uses 
>of IPsec tunnelling.

Just because the two look similar, that does not mean they are 
equivalent. Since BTNS focuses on creating SAs that are not 
authenticated via network layer mechanisms, the notion of the IDs 
used at this layer seems irrelevant to the BTNS focus.

Steve

---

From: Nicolas.Williams at Sun.COM (Nicolas Williams)
Date: Fri, 16 Dec 2005 14:05:23 -0600

Yes.

> layer.  The outer addresses act as locators, at least at the Internet  

But this deeper architectural issue is NOT specific to tunnels.

So, let's leave tunnels behind for a second and consider this
formulation of said architectural problem:

   IPsec, in its current form, requires a trade-off between dynamic
   addressing (the reality of today's IPv4 networks) and cryptographic
   binding of authenticated IDs and packet _flows_.

A slightly longer version:

   IPsec provides ID<->packet cryptographic binding and cryptographic
   protection for individual packets.

   IPsec does not provide cryptographic binding of IDs to packet _flows_
   associated with ULPs beyond that which is embodied in the IPsec
   configuration.  This is so because IPsec is not integrated with the
   ULPs.

   To provide such cryptographic binding of IDs to packet _flows_
   requires IPsec configuration to bind IDs to IP addresses, which makes
   IPsec configuration unmanageable where node renumbering events are
   common (as they often are, if nothing else because of DHCP/mobile
   nodes).

There is a way to add such cryptographic binding of IDs<->flows, but it
requires interfaces between IPsec and ULPs to manage such bindings and
between applications and ULPs to allow applications access to channel
bindings (not only for channel binding, but also so that applications
can determine if two channels have equal bindings, for example).

Other ways to achieve some degree of cryptographic binding of
IDs<->flows involve IPsec guessing ULP state from packet inspection
(much like NATs do).

Are there still other ways to solve this problem?  I can't think of any.

Nico
--