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

["Hancock, Robert" <[e-mail]>]

hi roland,

inline:

> -----Original Message-----
> From: Roland Bless [mailto:[e-mail]] 
> Sent: 01 August 2006 15:39
> To: Hancock, Robert
> Cc: Mark Doll; [e-mail]
> Subject: Re: [NSIS] Last Call: 'GIST: General Internet 
> Signaling Transport' to Proposed Standard (draft-ietf-nsis-ntlp)
> 
> 
> 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.

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.

> 
> > 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 =:->

tut tut ...

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

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

> b) if MA for NLI exists, send RESPONSE back via that MA

if it matches the re-use criteria (see the end of section 5.7.1).

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

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.

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

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

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

yes, but it really is minimal - there is no increase in the number of
messages and the message size change is marginal.

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

indeed they may. and i think it is useful to preserve this flexibility.
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.

cheers,

robert h.

> 
> Regards,
>  Roland
> 
> 

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