On Wed, Oct 14, 2009 at 02:36:20PM +0300, Tero Kivinen wrote:
> Nicolas Williams writes:
> > - Section 8.3, 1st paragraph, 2nd sentence: this sentence is
> > grammatically incorrect, and I'm unsure as to what is meant.
>
> This was commented already by others and was changed to:
>
> For example, when many TCP / UDP flows are established over
> one SA, a rekey produces a new SA which needs heuristics and will
> benefit from the existing flows.
>
> > I think what is meant is that if an intermediate node has seen a
> > stateful ULP flow over an ESP-NULL flow, and later the SA is changed
> > and the new flow looks like ESP-NULL and appears to contain a next
> > protocol header that matches that previously-seentateful ULP flow,
> > then chances are very good that the old ESP-NULL flow is abandoned
> > and replaced by the new one. In such situations the intermediate
> > node can simply change the old ESP-NULL state's lookup key.
>
> 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).
> > - Section 8.3.1, third paragraph: are you suggesting that intermediate
> > nodes drop TCP-looking packets to elicit retransmission?
>
> It says that "if a packets is dropped", i.e. it does not say whether
> the intermediate node does or does not do it, as that depends on the
> policy. If the intermediate node's policy is that no packets go
> through before they can be inspected meaning ESP-NULL detection needs
> to finish first before they can be inspected, that will cause all
> packets to be dropped while heuristics is in progress. This will cause
> next packets to be retransmissions.
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.
> 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.
> > - Section 9, 1st paragraph, 1st sentence: this is an odd sentence
> > construction. How about:
> > Attackers can always bypass ESP-NULL deep packet inspection by
> > using encrypted ESP (or some other encryption or tunneling method)
> > instead, unless the intermediate node's policy requires dropping
> > of packets that it cannot inspect.
> > - Section 9, 1st paragraph, 2nd sentence, rewrite:
> > Ultimately the responsibility for performing deep inspection, or
> > allowing intermediate nodes to perform deep inspection, must rest
> > on the end nodes.
> > - Section 9, 1st paragraph, last sentence: s/but in that/in which/
>
> Ok, took all of those in, here is the current version of section 9:
>
> <t>Attackers can always bypass ESP-NULL deep packet inspection by
> using encrypted ESP (or some other encryption or tunneling method)
> instead, unless the intermediate node's policy requires dropping
> of packets that it cannot inspect. Ultimately the responsibility
> for performing deep inspection, or allowing intermediate nodes to
> perform deep inspection, must rest on the end nodes. I.e. if a
> server allows encrypted connections also, then attacker who wants
> to attack the server and wants to bypass deep inspection device in
> the middle, will use encrypted traffic. This means that the
> protection of the whole network is only as good as the policy
> 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!
> > - Section 10.2, an informative reference to MOBIKE is needed. What
> > about multicast IPsec?
>
> Added reference to MOBIKE.
>
> I do not think multicast IPsec requires any special handling as the
> level what we need for them is already in the RFC4301/RFC4303. We do
> not really care about the keying protocols, we only care about the ESP
> packets and we use source address, destination address and SPI to
> indicate IPsec flow as specified in the RFC4301 and RFC4303.
Thanks.
A few more comments:
- Should there be an explicit threat model in the document? 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.
- 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.
I will review the pseudo-code at some point. I've reviewed the fast
path already, and it seemed OK (and it seemed to underscore the point
that state is actually needed for reasons other than optimization).
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).
Nico
--
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
