RE: GIST peering concern

hi,

sorry for the delayed response. there are some subtleties in this sort
of question.

i think there are two scenarios:

a) a non-endpoint being forced to peer because the GHC is zero, even
though it would rather not for policy or load issues.

b) an endpoint being forced to peer, even though it would rather not for
policy or load issues.

for (a), i think the right answer would be to allow the receiver to
generate the 'hop limit exceeded' error message (which it would have
done anyway if it did not host the NSLP at all, rather than hosting an
NSLP which happens not to want to peer). The implication would be just
to remove the clause "... , or if the GIST hop count has reached zero".
(That clause went in as a side effect of review discussions, but I think
this is an equally valid way to address the review in question.)

for (b), i think the question is how the endpoint should be allowed to
control its own load, and what feedback should be given to the sender
about that.

Note that it's always possible (in any protocol over an unreliable
transport, as GIST is in this scenario) to silently drop a message and
rely on the sender to back off and retransmit. As far as I understand
it, this is what TCP and IKE would do. 

Another possibility is to send a 'hard error' message ("I'm busy") to
which the sender would have to respond in some specific way. The danger
of that is a threefold security issue:
- you force the receiver to reveal information about its load
- you modify the sender behaviour with an unauthenticated message (not
necessarily fatal, but needs a tradeoff analysis)
- you provide a method for off-path attackers to create backscatter
(probably not a big issue here)
I don't believe any (widespread) protocols operate in this way, although
I'd be interested in counter-examples.

A third possibility is to be like the first possibility, but with the
option at the receiver to send an informative diagnostic saying "I'm
busy". The sender would behave as though a packet had been dropped (back
off and retry) but would know more about what is going on.

The current spec does the first. I think the second is not appropriate
(prepared to hear arguments). A diagnostic of the third type could be
added quite easily, since it does not actually change protocol operation
(happy to receive text suggestions ;-).)

cheers,

robert h.

> -----Original Message-----
> From: Roland Bless [mailto:[email protected]] 
> Sent: 14 November 2007 21:38
> To: Lauri J T Liuhto
> Cc: [email protected]
> Subject: Re: [NSIS] GIST peering concern
> 
> Hi Lauri,
> 
> Lauri J T Liuhto wrote:
> > While implementing our own NSLPs and the API between GIST 
> and NSLPs, 
> > we came across something in the current NTLP i-d we think 
> might be a 
> > problem.
> > 
> > In section 4.3.2 "Local Processing and Validation" it is 
> stated that: 
> > "The first option (peering) MUST be chosen if the node is the final 
> > destination of the Query message, or if the GIST hop count 
> has reached 
> > zero." We think this is problematic for at least two reasons.
> > 
> > 1) This removes flexibility from the NSLP application and 
> forces certain 
> >    behaviour. Thus it complicates NSLP application logic, 
> since the NSLP 
> >    must be aware of this exception to its peering "wishes".
> > 
> > 2) It could be possible to overload resources, such as 
> memory and UDP 
> >    send rate, of a GIST node. Sending Queries with an 
> (intentionally)  
> >    low GIST hop-count would lead to nodes being forced to 
> peer, though 
> >    it is stated in the same section (4.3.2), that a node 
> can decline 
> >    peering for "overload protection reasons".
> 
> I would agree here. However, I'm not sure what the rationale 
> was for the current text. Probably Robert has an answer.
> 
> > We suggest that an error message be defined for the case 
> when a flow 
> > endpoint does not wish to peer, or that the definition of the 
> > "Endpoint Found" message be extended to include this case. 
> Currently 
> > section 4.3.4 seems to state, that "Endpoint Found" can 
> only be sent 
> > when the NSLP is not present on the GIST node.
> 
> One must be careful to not open new attack possibilities by 
> causing error message backscatter. For diagnostic purposes I 
> would also recommend to send back an error.
> 
> Regards,
>  Roland
> 
> 
> _______________________________________________
> nsis mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/nsis
>