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

"Hancock, Robert" <robert.hancock@roke.co.uk> Mon, 31 July 2006 13:24 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7Xl2-0003sT-Pu; Mon, 31 Jul 2006 09:24:32 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7Xl2-0003sH-7Z for nsis@ietf.org; Mon, 31 Jul 2006 09:24:32 -0400
Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7Ww4-0001FU-KR for nsis@ietf.org; Mon, 31 Jul 2006 08:31:52 -0400
Received: from rsys002x.roke.co.uk ([193.118.201.109]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G7Wls-0005PX-5a for nsis@ietf.org; Mon, 31 Jul 2006 08:21:21 -0400
Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys002x.roke.co.uk (8.13.1/8.13.1) with ESMTP id k6VCKn2d000663; Mon, 31 Jul 2006 13:20:49 +0100
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: RE: [NSIS] Last Call: 'GIST: General Internet Signaling Transport' to Proposed Standard (draft-ietf-nsis-ntlp)
Date: Mon, 31 Jul 2006 13:20:49 +0100
Message-ID: <A632AD91CF90F24A87C42F6B96ADE5C57EC05C@rsys005a.comm.ad.roke.co.uk>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [NSIS] Last Call: 'GIST: General Internet Signaling Transport' to Proposed Standard (draft-ietf-nsis-ntlp)
Thread-Index: AcayWw3x8hbLUJEASQaTZYEExu/AqwCPxuWA
From: "Hancock, Robert" <robert.hancock@roke.co.uk>
To: Roland Bless <bless@tm.uka.de>
X-MailScanner-roke-co-uk: Found to be clean
X-MailScanner-roke-co-uk-SpamCheck:
X-MailScanner-From: robert.hancock@roke.co.uk
X-Spam-Score: -2.6 (--)
X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30
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 roland,


> Hi Robert,
> 
> [while playing around with our implementation, I reread
> parts of the current NTLP draft after a long time...and I have
> two -- maybe very silly/basic questions]:
> A)
> Possibly I missed the part in the draft, but is there any clear
> specification where exactly the RESPONSE must be sent in D-Mode
> (no MA-reuse)? I found only the following statements which
> are IMHO not very explicit about the exact destination:
> 
> "A Query always triggers a Response in
>    the reverse direction as the second message of the handshake."
> 
> "No Association: No MA exists.  GN2 sends the Response in D-mode
> directly to GN1, identifying itself and agreeing to the
> association setup."
> 
> "Query MUST elicit a Response.  This is a normally encapsulated D-mode
>    message with additional payloads."
> 
> and the "best hint" is in sec. 5.2.2 / NLI:
> 
>      The interface-address must be routable, i.e. it MUST be usable as
>       a destination IP address for packets to be sent back to the node
>       generating the signaling message, whether in D-mode or C-mode.
> 
> though it doesn't specify something about which destination
> address must be used for responses (and it would not be the
> appropriate section for this).
> 
> The example in fig.11 shows that the NLI i/f address
> is used in the response.
> 
> (The alternative to use the NLI address would be
> sending it back to the source in case of a set S-flag,
> but I guess that's not what the spec intends...)
> 
> 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.

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).

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 ;-)

> 
> 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.

cheers,

robert h.

> 
> Regards,
>  Roland
> 

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