[anonsec] 3401 and highjacking
kent at bbn.com
Thu Feb 16 16:16:44 PST 2006
I'm afraid your interpretation of my comments diverges from my intent
in several places. I'll try to clarify, using some different words
this time, and responding directly to your comments.
#1: do we agree on the "significance" of wildcard matching in the PAD?
Not exactly. What I said is that address-based packet filtering is a
necessary side effect of being able to operate at layer 3, especially
for intermediate systems like SGs. This says nothing about the use
of wildcards in the SPD or in the PAD. If we use only names (vs.
addresses) in the SPD and PAD for specifying entries that trigger SA
creation, we still can encounter problems due to address reuse:
- Alice (at address X) successfully creates an SA with Bob,
authenticating herself and matching a name-based PAD and SPD entry
- Carol comes along, is assigned address X, and tries to
create an SA with Bob, authenticating herself and matching a
different name-based PAD and SPD entry
- if both Alice and Carol connect to the same well-known port
on Bob's computer, and if both happen to choose the same local port,
we would now have two SAs that appear to be identical in terms of all
five traffic selector values. this poses a problem for Bob's IPsec
implementation, when it comes to mapping outbound traffic to the
right SA. (It's not a problem for inbound traffic, since such
traffic is demuxed based on SPI values chosen by Bob's IPsec
implementation). If Bob has a BITW IPsec implementation, and thus no
way to interact with Bob's computer to help resolve this ambiguity,
what should it do? The safe bet is probably to refuse Carol's SA
creation attempt, based on the reuse of X as the source address, to
be safe. This approach to resolving an address reuse problem of this
sort can be used irrespective of the reason that the conflict arises.
Michael's example was different in various details, but focused on
the potential problems caused by address reuse. He argued that there
was no good way to deal with this, since one approach allows for DoS
attacks against existing SAs, and the other discriminates against a
legitimate user who happens to get the same address assignment. I'm
in favor of door #2 here, and if I were the second user, I'd try to
renew my DHCP lease to get a different address.
My point here is that the type of problems we're discussing are not
really specific to the use of wildcards, and probably not specific to
the PAD design.
Because BTNS wants to create SAs for entities who possess no
authentication credentials, we cannot use the same set of criteria to
reject SAs that use addresses that collide with other SAs, as
suggested above. This exacerbates what I think is a relatively minor
issue. I'd call this a BTNS-generated problem.
#2 Did I say that pushing session protection down the stack is out of scope?
No. I explained why I disagreed with your comment that performance
was the motivation for pushing some security measures lower in the
stack, while other factors pushed security measures higher in the
stack. I also said that one could use SSL to address some (though not
all) of the use cases that were put forth as motivations for BTNS,
but that is out of scope for this WG, based on its current charter.
#3. Did I say that channel binding to IPsec SAs is infeasible.
Whether use of IPsec for channel binding is "feasible" is what the
output of this WG will determine. I suggested that when one tries to
split security service offerings between layers, one may create new
problems, problems that may not arise if one avoids crossing layer
boundaries in this fashion. Demonstrating the feasibility of using
IPsec for channel binding is the responsibility of those who propose
What we have discussed in the thread that was restarted from last
year, was that under some circumstances, certain choices of PAD and
SPD entries might be problematic, in principle. Michael also noted
that we tend to not see this happening, due to various details of SG
implementations. So, what might be a minor weakness of the 4301
model, in principle, may be a more serious problem for BTNS. I
consider this a challenge for BTNS; I do not think it is a rationale
to make significant changes to IPsec, to accommodate BTNS.
More information about the ANONSEC