[anonsec] 3401 and highjacking

[Stephen Kent]

Nico,

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 
such uses.

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.

Steve