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

From: Roland Bless <[email-masked]>
Date: Tue, 01 Aug 2006 16:39:07 +0200

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis

---

From: "Hancock, Robert" <[email-masked]>
Date: Thu, 10 Aug 2006 15:44:25 +0100

hi roland,

i've created issues and updated text for both of these at
http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/issue113
and 
http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/issue114

you might like to take a look and see if they are clear.

cheers,

robert h.

> -----Original Message-----
> From: Roland Bless [mailto:[email-masked]] 
> Sent: 08 August 2006 09:28
> To: Hancock, Robert
> Cc: Mark Doll; [email-masked]
> Subject: Re: [NSIS] Last Call: 'GIST: General Internet 
> Signaling Transport' to Proposed Standard (draft-ietf-nsis-ntlp)
> 
> 
> Hi Robert,
> 
> > inline:
> 
> dito
> 
> >> -----Original Message-----
> >> From: Roland Bless [mailto:[email-masked]] 
> >> Sent: 01 August 2006 15:39
> >> To: Hancock, Robert
> >> Cc: Mark Doll; [email-masked]
> >> Subject: Re: [NSIS] Last Call: 'GIST: General Internet 
> >> Signaling Transport' to Proposed Standard (draft-ietf-nsis-ntlp)
> >>
> >>
> >> Hi Robert,
> >>
> > it is not quite that bad. i can think of some more deterministic
> > text (see below). however, the key message from (1) in particular
> > would be something like:
> > "once the Querying has received a Response message, it MUST ignore 
> > the addressing data from the IP header"
> > (or something like that). to some extent, i don't care 
> about fuzzyness
> > of sender behaviour if it is not relevant to the receiver.
> 
> Hmm, in this case you mean sender/receiver of GIST messages, not
> data sender...
> 
> > i would guess:
> > object value error with subcode 1, sent back to the IP source
> > if S=1 else logging an error locally. (section 5.6 says this to
> > some extent, but we don't try to define absolutely every 
> condition...)
> 
> Yep. That's ok.
> 
> > if it matches the re-use criteria (see the end of section 5.7.1).
> 
> Sure.
> 
> > i think you mean "if S *is* set". i would probably make this a
> > SHOULD given that we always initially have S=0 in the first Query.
> 
> Yep, sorry I confused the S-Flag setting.
> 
> > i probably use the word 'spoofed' here less precisely. by 'spoofed
> > query' i mean 'any query that the receiver of the Response did not
> > actually send' (not only with a forged source address).
> > 
> >> as benefit.
> > yes, but it really is minimal - there is no increase in the 
> number of
> > messages and the message size change is marginal.
> 
> Yep,  however it should be mentioned in the security considerations.
> 
> >> I meant sanity checks on the side of the responder:
> > indeed they may. and i think it is useful to preserve this 
> flexibility.
> 
> Agreed.
> 
> > there are constraints on both the IP source and NLI 
> interface-address;
> > the former are to do with possible implementation restrictions and
> > the latter to do with route change detection for some MRMs. 
> we cannot
> > rule out that those constraints will always be satisfiable 
> by the same
> > address.
> 
> 
> Yep,
>  Roland
>