Subject: RE: [NSIS] Handshake

From: "Hancock, Robert" <[email-masked]>
Date: Tue, 24 Jan 2006 16:59:39 -0000

hi luis,

basically, you are correct that there are two options that GIST could take. which one is appropriate depends on the needs of the signalling application that is sending the message; my feeling is that your option (2) is the natural default (since if you strictly follow option (1) you will not get any replies since there is no reverse routing state installed).

with this in mind, the API allows the signalling application to express the fact that there is no need for routing state to be set up (see section B.1) as a special case.

BTW we detected that some of the discussion of the validation checks in sections 4.3.1/2 was possibly somewhat confusing/overlapping; the updated text proposed for version -09 is attached below.

hope this helps,

robert h.

======================================================================

4.3.1.  Message Reception

   Messages can be received in connection or datagram mode, and in the
   latter case with two types of message encapsulation.

   Reception in connection mode is simple: incoming packets undergo the
   security and transport treatment associated with the messaging
   association, and the messaging association provides complete messages
   to the GIST layer for further processing.

   Reception in datagram mode depends on the message type.  'Normal'
   messages arrive UDP encapsulated and addressed directly to the
   receiving signaling node, at an address and port learned previously.
   Each datagram contains a single message which is passed to the GIST
   layer for further processing, just as in the connection mode case.

   Where GIST is sending messages to be intercepted by the appropriate
   peer rather than directly addressed to it (in particular, Query
   messages), these are UDP encapsulated with an IP router alert option.
   Each signaling node will therefore 'see' all such messages.  The case
   where the NSLPID does not match a local signaling application at all
   is considered below in Section 4.3.4; otherwise, it is again passed
   up to the GIST layer for further processing.

4.3.2.  Local Processing and Validation

   Once a message has been received, it is processed locally within the
   GIST layer.  The GIST hop count MUST be decremented immediately the
   message has been received.  Further processing depends on the message
   type and payloads carried; most of the GIST payloads are associated
   with state maintenance and details are covered in Section 4.4.

   In the case of a GIST-Query, there is an interaction with signaling
   application policy to determine which of two courses to follow:

   1.  The signaling application wishes to become a signaling peer with
       the Querying node.  GIST MUST continue with the handshake process
       to set up message routing state, as described in Section 4.4.1.
       The application MAY provide an NSLP payload for the same NSLPID,
       which GIST will transfer in the GIST-Response.

   2.  The signaling application does not wish to set up state with the
       Querying node and become its peer.  GIST MUST propagate the
       Query, similar to the case described in Section 4.3.4.  No
       message is sent back to the Querying node.  The application MAY
       provide an updated NSLP payload for the same NSLPID (which will
       be used in the Query message forwarded by GIST).

   This interaction with the signaling application, including the
   generation or update of an NSLP payload, SHOULD take place
   synchronously as part of the Query message processing .  In terms of
   the GIST service interface, this can be implemented by providing
   appropriate return values for the primitive that is triggered when
   such a message is received; see Appendix B.2 for further discussion.

   For all other message types, the GIST payloads are processed as
   described in Section 4.4.  The remainder of the GIST message consists
   of an NSLP payload, which is delivered locally to the signaling
   application identified by the NSLPID.  The format of the payload is
   not constrained by GIST, and the content is not interpreted.
   Delivery is subject to the following validation checks:

   o  if the message was explicitly routed (see Section 7.1.4) or is a
      Data message delivered without routing state (see Section 5.3.2),
      the payload is delivered but flagged to the receiving NSLP to
      indicate that routing state was not validated;

   o  else, if there is no routing state for the MRI/SID/NSLPID the
      message MUST be rejected with a "No Routing State" error message
      (Appendix A.4.4.5);

   o  else, if the message arrived on an association which is not
      associated with the MRI/NSLPID/SID combination given in the
      message, the message MUST be rejected with an "Incorrectly
      Delivered Message" error message (Appendix A.4.4.4);

   o  else, the payload is delivered as normal.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Luís Cordeiro
> Sent: 16 January 2006 12:06
> To: [email-masked]
> Subject: [NSIS] Handshake
> 
> 
> Hi all,
>  
> I have a last minute dough about the usage of the handshake 
> (query and response messages) when a NSLP requests GIST to 
> send a message with no security and no reliability (UDP case).
>  
> I see in here two approaches:
>  
> 1) Because we don't want reliability and security the message 
> is sent in a data message and no handshake is needed. (in the 
> receiver GIST the NSLP payload is directly sent to the NSLP 
> and no states are stored)
>  
> 2) Before sending the NSLP payload the handshake must be done 
> (query and response messages) and only after the data massage 
> can be sent. In this case all data messages received that 
> don't have any MRS state will result in a "No Routing State" 
> error message.
>  
> Best regards,
> Luís Cordeiro
>  
> 

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

---

From: [email-masked]
Date: Tue, 24 Jan 2006 18:37:21 +0000

Hi, Robert,

After read your reply careful, I had more doubts and want to discuss 
more about that with you.

According to section 5.5 "Message Type/Encapsulation Relationships" of 
draft-ietf-nsis-ntlp-08, I don't see there is the need to have a 
handshake (query/response) first before sending out one NSLP data which 
does not request reliability and security. Section 5.5 states that the 
gist should use the "D-Mode Normal" encapsulation method to send a 
GIST-Data "if routing state exists for the flow but no appropriate 
messaging association" and should use the "D-Mode Query" encapsulation 
method to send it "if no routing state exists and the MRI can be used 
to derive the query encapsulation". As for Path-Coupled MRM, the MRI 
certainly can be used to derive the query encapsulation (i.e., the 
destination address of the flow), thus according to section 5.5, gist 
does not need to have any handshake first and can send the Gist-Data 
directly via the "D-Mode Query" encapsulation.

Moreover, if the Gist-Data is received via interception by the 
downstream NSIS node, it can obtain the peer information (peer identity 
and peer interface) from the NLI object of the received Gist-Data 
message and then set up one-time upstream routing state if wanted 
(depending on local policy), i.e., if the NSLP has message to sent back 
to the upstream peer, it can send it via "D-Mode Normal" encapsulation 
to that peer while without the overhead cost of handshake. Then, does 
it mean that option (1) should be preferred?

Anyway, if we decide that option (2) should be prefered, then I think 
the description texts about Message Type/Encapsulation Relationships in 
section 5.5 also need be changed accordingly like this: "if no routing 
state exists and no routing state needs to be established and the MRI 
can be used to derive the query encapsulation", then Gist-Data should 
be sent via the "D-Mode Query" encapsulation method.

Regards,

Jia

Quoting "Hancock, Robert" <[email-masked]>:

> hi luis,
>
> basically, you are correct that there are two options that GIST could 
> take. which one is appropriate depends on the needs of the signalling 
> application that is sending the message; my feeling is that your 
> option (2) is the natural default (since if you strictly follow 
> option (1) you will not get any replies since there is no reverse 
> routing state installed).
>
> with this in mind, the API allows the signalling application to 
> express the fact that there is no need for routing state to be set up 
> (see section B.1) as a special case.
>
> BTW we detected that some of the discussion of the validation checks 
> in sections 4.3.1/2 was possibly somewhat confusing/overlapping; the 
> updated text proposed for version -09 is attached below.
>
> hope this helps,
>
> robert h.
>

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.