Nicolas Williams writes:
> On Wed, Oct 14, 2009 at 02:36:20PM +0300, Tero Kivinen wrote:
> > Yes. That was what I tried to say. Do you think my already changed
> > sentence is ok, or do we need to explain it more.
>
> Well, the heuristics will benefit from the information cached for the
> TCP/UDP flow over the previous SA. "...benefit from the existing flows"
> doesn't quite get that point across (though it's the only realistic
> meaning).
Changed the text still more:
Generic protocol checking is much easier with pre-existing state.
For example, when many TCP / UDP flows are established over one
IPsec SA, a rekey produces a new SA which needs heuristics to
detect its parameters, and those heuristics benefit from the
existing TCP / UDP flows which were present in the previous IPsec
SA. In that case it is just enough to check that if a new IPsec SA
has packets belonging to the flows of some other IPsec SA
(previous IPsec SA before rekey), and if those flows are already
known by the deep inspection engine, it will give a strong leaning
that the new SA is really ESP-NULL.
> But surely actively trying to elicit retransmissions could be used
> as a way to get enough information to classify a flow... The
> retransmissions should have different MACs, thus retransmissions
> help resolve ambiguities, even if the policy isn't to drop packets that
> cannot be inspected.
I would be quite hesitant to add text which actively tries to elicit
more retransmissions. If packets are dropped because of policy reasons
and that triggers retransmissions which helps heuristics, then that is
good. If packets are passed through then we can most likely use
heuristics over multiple packets to gain same information.
> > If the policy is so that packets are passed, even when we cannot yet
> > inspect them, then the next packet still might be to the same flow.
>
> I see. Having a policy that says "drop packets that can't be inspected"
> actually helps resolve ambiguities if the end nodes retransmit.
Yes, but it also helps to resolve ambiguities, if we see multiple
packets to the same flow, i.e. get 3 TCP packets having same source
and destionation IP and ports, and first having SYN bit, next reply
having SYN/ACK and next one having ACK (with all of them with expected
sequence numbers etc).
> > enforcement and protection of the end node. One way to enforce
> > deep inspection for all traffic, is to forbid encrypted ESP
> > completely, in which case ESP-NULL detection is easier, as all
> > packets must be ESP-NULL based on the policy, and further
> > restriction can eliminate ambiguities in ICV and IV sizes.</t>
> ^
> s
>
> Great!
Fixed.
> A few more comments:
>
> - Should there be an explicit threat model in the document?
I am not sure if it belongs to this document, or to the WESP or as
separate document. I agree that having explicit threat model could
probably help understanding the problem, but I am not sure I am
correct person to write such.
> I think
> the threat model is this:
>
> - End nodes trying to access inappropriate data, end nodes trying
> sneak confidential data out, but without collusion with other end
> nodes outside the network.
>
> - Malware (since deep inspection could find malware and terminate
> flows before malware downloads complete).
>
> The first one shows how simple it is to defeat deep packet
> inspection: just find a peer to collude with.
There is also some cases where this can be used even when there is no
real threat, i.e. statics, and log gathering etc.
> - A security considerations note about the security impact of forcing
> the use of ESP-NULL (and/or WESP) would be nice. Specifically a note
> about the increased risk of sending confidential information where
> eavesdroppers can see it.
Added note:
<t>Using ESP-NULL or especially forcing using of it everywhere
inside the enterprice can have increased risk of sending
confidential information where eavesdroppers can see it.</t>
> The thought occurred that the pseudo-code could be expressed as a BSD
> Packet Filter program. From what I can tell BPF does not have
> instructions by which one can implement state caching, but you could
> still implement, and _test_, large parts of the code in the appendix as
> BPF programs. I wouldn't demand that -- it's a lot of work for a
> feature that we all seem to agree is not exactly hot (and it might mean
> doing implementation work for some vendors for free).
I do not expect the pseudo-code to include all required operations,
and I do not think it would be good idea to put executable code in the
RFC. It is meant to be as example pseudo-code, not final
implementation.
I think it might be better if someone could take that pseudo-code, and
implement as much as possible of it as BSD packet filter or some other
filtering language and put that out as open-source implementation.
This might be suitable exercise for some student out there... :-)
--
kivi...@iki.fi
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
