Re: Traffic selectors, fragments, ICMP messages and security policy problems

[Stephen Kent <kent@bbn.com>]

At 4:01 PM +0200 3/14/04, Markku Savela wrote:
>  > From: Stephen Kent <kent@bbn.com>
>
>>  >Yes, but at least my current implementation rejects packets that are
>>  >protected validly with ESP or AH, but policy calls for no protection
>>  >(or if policy calls for different protection).
>>
>>  that's an interesting "feature." I can understand why you might
>>  choose to do that, e.g., for fault detection and isolation, but I'm
>>  not sure it is needed from a security perspective.
>
>This "feature" may have real uses. The following example is a bit
>artificial, but it may serve for now:
>
>  A mobile node M is talking to a server S, hosting some database
>  application. S is behind a normal Firewall (FW), which the admins
>  configure to pass IPSEC traffic to S, knowing it only *accepts* and
>  requires the database traffic to be protected.
>
>  M <============ FW ====== DataBaseAccess ===> S

the diagram is missing a SG, between the FW and S, right?

>  S is also hosting other services (WEB, SMTP, etc), which are used in
>  clear and it is assumed that the FW filters dangerous stuff from
>  clear traffic.
>
>  If M gets infected with something, M could quite easily send some
>  harmful stuff using the Database IPSEC connection, if S accepts
>  anything else that just happens to be validly protected by the IPSEC.

OK, this is a better explanation. the concern is that if we carry 
traffic other than what was intended to travel via the SA, then even 
if we are offering it better protection en route, we may violate the 
access control scheme at the receiver, if the receiver is configured 
to pass non-IPsec traffic via one path, and IPsec via another.

Steve