Re: [NSIS] Last Call: 'GIST: General Internet Signaling Transport' to Proposed Standard (draft-ietf-nsis-ntlp)

Roland Bless <bless@tm.uka.de> Tue, 01 August 2006 14:39 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7vP4-0007ru-IO; Tue, 01 Aug 2006 10:39:26 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7vP3-0007gG-1V for nsis@ietf.org; Tue, 01 Aug 2006 10:39:25 -0400
Received: from iramx1.ira.uni-karlsruhe.de ([141.3.10.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7vP1-0007Tc-He for nsis@ietf.org; Tue, 01 Aug 2006 10:39:25 -0400
Received: from i72ms2.tm.uni-karlsruhe.de ([141.3.70.17] helo=smtp.ipv6.tm.uni-karlsruhe.de) by iramx1.ira.uni-karlsruhe.de with esmtps id 1G7vOm-00078z-Gc; Tue, 01 Aug 2006 16:39:12 +0200
Received: from vorta.ipv6.tm.uni-karlsruhe.de (vorta.ipv6.tm.uni-karlsruhe.de [IPv6:2001:638:204:6:207:e9ff:fe0c:5e44]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id 2FE3E864E; Tue, 1 Aug 2006 16:39:08 +0200 (CEST)
Received: from localhost ([127.0.0.1]) by vorta.ipv6.tm.uni-karlsruhe.de with esmtp (Exim 4.44) id 1G7vOl-0006El-RD; Tue, 01 Aug 2006 16:39:07 +0200
Message-ID: <44CF678B.7000608@tm.uka.de>
Date: Tue, 01 Aug 2006 16:39:07 +0200
From: Roland Bless <bless@tm.uka.de>
Organization: Institute of Telematics, University of Karlsruhe
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060111 Thunderbird/1.5 Mnenhy/0.7.3.0
MIME-Version: 1.0
To: "Hancock, Robert" <robert.hancock@roke.co.uk>
Subject: Re: [NSIS] Last Call: 'GIST: General Internet Signaling Transport' to Proposed Standard (draft-ietf-nsis-ntlp)
References: <A632AD91CF90F24A87C42F6B96ADE5C57EC05C@rsys005a.comm.ad.roke.co.uk>
In-Reply-To: <A632AD91CF90F24A87C42F6B96ADE5C57EC05C@rsys005a.comm.ad.roke.co.uk>
X-Enigmail-Version: 0.94.0.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Spam-Score: -4.2 (----)
X-Spam-Status: No
X-Spam-Report: -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.2 AWL AWL: From: address is in the auto white-list
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248
Cc: Mark Doll <doll@tm.uka.de>, nsis@ietf.org
X-BeenThere: nsis@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Next Steps in Signaling <nsis.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/nsis>, <mailto:nsis-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:nsis@ietf.org>
List-Help: <mailto:nsis-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/nsis>, <mailto:nsis-request@ietf.org?subject=subscribe>
Errors-To: nsis-bounces@ietf.org

Hi Robert,

>> However, I would really like to see a clear statement like:
>> GN2 sends the Response in D-mode directly to GN1, using
>> the interface-address as destination addess as specified
>> in the NLI of the query and the source port of the query
>> as destination port of the response.
> 
> there are three parts to the answer here:
> 
> 1) the underlying requirement is to get the message to the right
> node; apart from this, the encapsulation doesn't matter.

That sounds logical, but it is quite fuzzy...
I guess this will lead to different results depending
on the particular implementation.

> 2) for the scenarios which are in scope of the spec (i.e. no
> legacy NATs) the correct (or at least intended) behaviour is 
> as you put it above.
> 
> 3) it is not impossible that some approach to traversal of
> legacy NATs would require sending the Response back to the 
> Query source. those approaches are not worked out in this
> draft, but it is the basis of the approach described in
> draft-pashalidis-ietf-nsis-gist-legacynats-00 for example
> (see section 5).

NATs cause headache and pain...so I probably skipped that
part =:->

> so i can imagine writing something more explicit, but i
> wouldn't want to pin it down to the extent of ruling out
> the flexibility required by (3), expecially given the overall
> criterion (1) - that it shouldn't matter provided it works.
> more text suggestions welcome ;-)

Hmm, actually I don't know how one could implement a robust
scheme that works in all situations. I understood at least
this:
a) if no MA for given NLI exists then use D-Mode and send RESPONSE
   back to NLI (BTW: what if NLI is obviously useless, e.g. ::,
   0.0.0.0, ::1 or unrouteable, should we send back an error to
   the source - I guess we have no suitable error code for that yet?)
b) if MA for NLI exists, send RESPONSE back via that MA
c) the GIST node could also send the response back to the source if
   no S-flag is set. Has this precedence over a)? Only in certain
   environments?

So usually I would use a) and b) but you also suggest that c)
might be useful in certain NAT scenarios...

>> B)
>> if the response must be sent back to what is specified in the
>> NLI, this possibly opens up reflection attacks. This should be
>> mentioned in the security considerations section and I'm not quite
>> sure whether any sanity checks are possible to prevent this.
> 
> this is the intention (one of the intentions) of the 3rd requirement
> on the Q-cookie in section 8.5 (easily validated ... to discard
> responses to spoofed queries). i don't see what other sanity 
> checks are possible to prevent this.

This only covers a part of my question. So an NSIS node
will discard responses to spoofed queries, this is good.
Assume that an attacker A sends a query with the NLI containing the
address of the victim V. The responder R will nevertheless
answer the query and send the RESPONSE to V. This is a reflection
attack and doesn't require spoofing the source address of the query
(which can be A's address).
In case the response is larger than the query the attacker cannot
only hide behind the reflector, he can also use slight amplification
as benefit. I meant sanity checks on the side of the responder:
it is not easily possible to check that NLI and source address
correspond to each other, because they may intentionally differ...

Regards,
 Roland


_______________________________________________
nsis mailing list
nsis@ietf.org
https://www1.ietf.org/mailman/listinfo/nsis