Subject: Re: [NSIS] NATFW NSLP; No solution provided for attack described in section 5.5.3

From: Martin Stiemerling <[email-masked]>
Date: Thu, 4 May 2006 16:42:16 +0200

Hi Ali,

my reply is two-fold:
a) measures already included in the NATFW NSLP to mitigate parts of  
this attack
b) things still not handled

For a)
The rule for firewalls supporting the NATFW NSLP is to block all  
inbound NATFW request messages by default. A DR must first tell the  
upstream firewall(s) its desire to receive NATFW request messages by  
using REA. Afterwards it can receive these request messages. This  
means, that the described attack is only possible if the DR has  
signaled with REA.

The threat description describes two cases:
i) IP address and/or additional information about the data flow is  
known in advance, for instance, DS' IP address or transport protocol
ii) Nothing is known in advance about the DS, for instance, if DR is  
a server and waiting for arbitrary clients to connect.

For case i), the DR can specify this information in its MRI or the  
REA message.
Case ii) leads over to point b)

For b)
In this case, there is not much information about DS available. This  
is typically the case for a server behind a firewall, i.e., all  
possible attacks on a server apply here as well.

One way of mitigate this is the usage of an authorization framework,  
as you have described it. The current version of the NSLP describes  
the NATFW_CREDENTIAL object, which can be used in this context. I  
have to admit, that this new object has not been reflected in the  
particular section of the security considerations.

The description is true for the case in Section 5.5.4 (NAT) as well.  
The countermeasure, similar to a) in this email, is the usage of the  
DTINFO_IPV4 object.

   Martin

Am 21.04.2006 um 00:11 schrieb Ali Fessi:

> Dear NATFW NSLP authors,
>
> there is currently no security requirement derived from the threat  
> described in Section 5.5.3 (Data Receiver (DR) behind a firewall);
>
> although it is a very realistic attack!
>
> However, looking at the whole document, a solution for resolving  
> this attack can be actually provided:
>
> - either by relying on an authorization framework (authorization  
> tokens, SAML, etc.)
>
> - or by relying upon GIST or underlying protocols, for providing  
> hop-by-hop authentication;
>
> So the derived security requirements could be updated accordingly  
> (i could provide a suggestions for some text, if you want)
>
> Also: the attack described in section 5.5.4 is actually the same  
> except the middlebox function is a NAT instead of firewall; but  
> this doesn't make a difference.
>
> Regards,
> Ali
> -- 
> Ali Fessi
> University of Tuebingen, Germany
> _______________________________________________
> nsis mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/nsis

_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis