[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ipsec
Subject:    Re: [Ipsec] Fwd: I-D Action:draft-hoffman-esp-null-protocol-00.txt
From:       Tero Kivinen <kivinen () iki ! fi>
Date:       2007-09-20 15:33:15
Message-ID: 18162.37563.74060.864931 () fireball ! kivinen ! iki ! fi
[Download RAW message or body]

mcgrew writes:
> I agree that many people see value in inspection at higher layers.  But
> certainly conventional ACLs using addr/port/protocol are still very common
> and very useful.

You cannot use such simple tests to detect the problems you describe
in the end i.e. subverted node sending invalid data to the correct
host using proper IPsec policy.

> True, but we would not want to require a firewall to generate and maintain
> state based on packets that it receives from the outside, such as ESP-NULL
> packets.  

In normal case they do that for all traffic, not only ESP-NULL
packets. I.e. firewalls usually do keep track of all incoming and
outgoing TCP flows, and keeping track of flows inside ESP-NULL packets
belongs to same category, thus do not add any more work.

The question is whether those very simple filter machines which only
know how to filter packets based on IP and port numbers, need to have
feature where they can look in to the ESP-NULL packets. My guess is
that, such feature is needed and added to more high-end firewalls,
which will be already doing statefull checking of the packets.

> > I mean if someone wants to attack something which is behind firewall
> > that will let both ESP-NULL and encrypted ESP packets through the
> > firewall, why would the attacker use ESP-NULL where the firewall might
> > detect the attacks. He would of couse use the encrypted ESP packets
> > instead as then he is sure the firewall cannot detect the attack.
> 
> Well, an attacker would be motivated to use ESP-NULL in order to attack a
> host that had a policy that only accepted NULL encryption.  In this case,
> the attacker would know that the plaintext was available for inspection, but
> would be hoping that the attack would go unnoticed.

But IPsec policy already mandatory features that require it to check
that packets coming in must match the selectors used when creating the
IPsec SA. I.e. valid implementation of the recipient will throw the
packets away which do not match its security policy, thus those
packets that would be thrown away by simple firewall checking the IP
and port numbers inside the ESP-NULL packets, will be thrown away by
the recipient IPsec stack also as they do not match the policy
specified there (or the policy is incorrect, but that was not the case
here). 

> > So for the filtering to be effective the firewall need to block all
> > ESP packets which are not ESP-NULL destioned to the host he is trying
> > to protect, as the firewall cannot trust the node he is protecting to
> > have secure IPsec policy rejecting invalid ESP encrypted connections.
> 
> One of the main motivations for inspection inside of auth-only ESP, I think,
> is the case in which an ESP sender/receiver has been trusted, but may be
> subverted.  In this case, the host does have the correct policy, but it has
> been the victim of a worm or some other form of malware.   Your analysis (if
> I'm understanding it) disregards this case.

Detecting subverted sender is much easier in the real recipient of the
packet than in the firewall in the middle. The end node has more
information about the situation and can do much stricter checking of
the data than firewalls in the middle, who are missing the big
picture. 
-- 
kivinen@safenet-inc.com


_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec
[prev in list] [next in list] [prev in thread] [next in thread]