Subject: [NSIS] RE: GIST Late State Insallation: Does Responding NSLP wait for NetworkNotification?

From: "Hancock, Robert" <[email-masked]>
Date: Fri, 9 Dec 2005 11:17:43 -0000

hi thomas,

there are two points here:

*) i think the idea of indicating that routing state has been
created via a NetworkNotification is a good clarification, which
can be added to the API description. (will be in -09.)

*) however, on the initial point you raise, about how to handle
an NSLP which has data to send 'against the flow', I would handle
the NSLP/GIST interaction differently.

- if there is a 'one-shot' response at the NSLP level, that can
be generated synchronously and piggybacked in the Response message
(as previously discussed).

- if the NSLP has some more significant data to send to that flow,
then there actually is no need to constrain the GIST level to 
carry out late state installation at all. the point of the late
state installation is to avoid a state exhaustion attack on GIST
by creating half-complete routing state for large numbers of flows.
however, if there is already state in the NSLP, either we know that
this is a 'useful' flow for which it makes sense to keep state
early, or we know that the NSLP itself is vulnerable to a state
exhaustion attack, which GIST cannot defend it from. In this case,
it makes sense for GIST to handle the Query by going to the 
"Awaiting Confirm" state (see case (2) in section 6.2). In that
state, the NSLP can generate Data messages which will be queued
in GIST until the routing state is set up.

(in theory, the selection of which state GIST should go into 
could be indicated via the return values from the RecvMessage
API call. however, i feel that is going too deep into implementation
aspects for the GIST spec itself.)

cheers,

robert h.

> -----Original Message-----
> From: Thomas Herzog [mailto:[email-masked]] 
> Sent: 25 November 2005 17:35
> To: [email-masked]; Hancock, Robert
> Subject: GIST Late State Insallation: Does Responding NSLP 
> wait for NetworkNotification?
> 
> 
> Hi all, 
> 
> I am currently in the phase of testing and validating our 
> GIST implementation, 
> for which I am able to use the GistPing tool of the folks 
> from Goettingen 
> which currently proves to work just fine as a lightweight 
> testing NSLP.
> 
> So far, I am now facing the task of validating our Late State 
> Installation 
> mechanism, so a thought occured to me:
> 
> Does the Responding Node's NSLP have to wait for a 
> NetworkNotification after 
> having told GIST to establish backwards routing state until 
> it sends back 
> messages itself?
> 
> I see the problem in using Late State Installation in the 
> case, the RN NSLP 
> wants to directly answer to a received incoming Message.
> 
> GIST discards any information about the Flow after having 
> sent the response, 
> thus a SendMessage from the Responding NSLP prior to the 
> final State Setup 
> would lead to an upstream Query to be sent.
> 
> This would be a severe problem. So I think the Responding 
> Node's NSLP should 
> wait after receiving/answering the initial RecvMessage for the 
> NetworkNotification which tells it that state is set up!
> 
> Has this been covered in the NSLP draft?
> 
> Currently (draft-08), we are signaling "Route changed, status 
> XY" and "Last 
> Node" via NetworkNotifications. I think, this should be 
> extended by "Route 
> initially set up", because in this case, there is no Route 
> changed and the 
> information that the messaging path is available should be 
> also vital to a 
> NSLP?
> 
> Can someone clarify this?
> 
> Cheers, Thomas
> 

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