Subject: [NSIS] GIST peering concern

From: Lauri J T Liuhto <[email-masked]>
Date: Mon, 5 Nov 2007 15:02:10 +0200 (EET)

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

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.

 Regards,
 Nuutti, Teemu and Lauri

-- 
Lauri Liuhto

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

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 14 Nov 2007 10:35:04 +0100

Hi,

I haven't seen any reply to this comment. Please do as I will not accept
outstanding issues when going forward with the doc.

Cheers

Magnus

-- 

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM/M
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Roland Bless <[email-masked]>
Date: Wed, 14 Nov 2007 22:38:07 +0100

Hi Lauri,

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

> 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

---

From: "Hancock, Robert" <[email-masked]>
Date: Fri, 16 Nov 2007 10:58:23 -0000

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-masked]] 
> Sent: 14 November 2007 21:38
> To: Lauri J T Liuhto
> Cc: [email-masked]
> 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.
> > 
> > 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
> 
>