Subject: RE: [NSIS] Handshake

From: "Hancock, Robert" <[email-masked]>
Date: Wed, 25 Jan 2006 11:26:54 -0000

hi jia,

please see in-line.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: 24 January 2006 18:37
> To: Hancock, Robert
> Cc: [email-masked]
> Subject: RE: [NSIS] Handshake
> 
> 
> 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 
       ^^^^^^

this is a misinterpretation of the table. section 5.5 says what
is *possible*; it does not say what GIST SHOULD or MUST do. 
elsewhere in the specification (e.g. 6.1) it is stated that routing
state should be created unless the signalling application says
otherwise.

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

but note that the message will be delivered at the far end flagged as 
coming from a source which has gone through no type of validation
of routing correctness (see B.2). so the signalling application may
choose to disregard it etc.
 
> 
> 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?

no: although it is logically possible to infer upstream routing
state from a single message, the specification basically does
not allow this because of the vulnerabilities it opens to spoofing
attacks, which can affect both the node receiving the message and
the node receiving the reply. the only exception is for error
messages (which are a special case, since error messages never
lead directly to further messages or state creation and can always
be ignored).

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

i have added some text to 5.5 stating that the rest of the specification
is authoritative for working out when routing/MA state should be created.

cheers,

robert h.

> 
> 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.
> >
> > 
> ======================================================================
> >
> > 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
> >
> 
> 
> 
> ----------------------------------------------------------------
> This message was sent using IMP, the Internet Messaging Program.
> 
> 

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