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