Subject: RE: [NSIS] GIST: Switching to C-Mode after setup on behalf of theresponder node

From: "Hancock, Robert" <[email-masked]>
Date: Fri, 4 Nov 2005 14:17:00 -0000

Hi Thomas,

You are right that basically this is not possible. The underlying
assumption is that the querying node is always in charge of
initiating things to do with messaging association policy. My
expectation is that a signalling application running on a node
should ensure that the GIST policies will lead to something 
appropriate for carrying the NSLP traffic *in either direction*.
After all, even though the QN NSLP doesn't know which peer it is
talking to, it does at least know what NSLP it is talking to,
in which case it is reasonable to require it to know about the
necessary transport/security properties that it should request.

I think trying to do something more sophisticated also leads to
several problems (see below in line).

cheers,

robert h.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Thomas Herzog
> Sent: 04 November 2005 09:44
> To: [email-masked]
> Subject: [NSIS] GIST: Switching to C-Mode after setup on 
> behalf of theresponder node
> 
> 
> Hi, together,
> 
> I find it very hard to install a Messaging Association on 
> behalf of the 
> responder node, when there is currently only D-Mode set up for the 
> connection.

Correct.

> 
> On the QN side, the QN can do so by using a refresh cycle and 
> asking for stack 
> proposal and switching to C-Mode by initiating a MA with the confirm.
> 
> On the RN side, GIST will get a SendMessage call from a NSLP 
> (which needs 
> C-Mode), find Routing State and finds out that it has only 
> D-Mode available.
> 
> What to do now, as a Refresh cycle cannot be initiated from the RN.
> 
> A new Handshake initiated from the RN would also be quite 
> problematic, as the 
> QN is in some state of its QN-SM, thus it will not respond to 
> queries for the 
> already installed state (and will not transit into Responder Role).

it may even be impossible to initiate the handshake from the
'RN' at all: this would require to send a Query, but encapsulating 
the Query correctly for the RN->QN direction can only be done for
some MRMs and then only under special circumstances. So we would 
need to define additional query encapsulations where the destination
IP address was derived from known routing state. And then the 
routing state refresh would become problematic (because repeating
the handshake would certainly not detect any route changes).

> 
> What to do in that case?
> 
> It is thinkable, that such a case happens, imagine a 
> Responding NSLP not 
> requiring C-Mode (as it knows, the connection is set up 
> 'unreliable'/'insecure'), but maybe it wants to transmit a 
> large amount of 
> data which cannot be sent in D-Mode.

see main body of email.

> 
> Wouldn't it be a good idea to include a new rule in QN-SM in State 
> "established" to kill all state and start RN-SM if a GIST 
> query arrives for 
> the state?

This is conceivable, but think of the denial of service implications...
(and a number of other issues).

> 
> Thus a RN may "upgrade" the connection properties by initiating a new 
> handshake, starting QN-SM and the "roles" would be swapped?

A fallback case would be for the NSLP at the RN to ask its upstream peer
to upgrade GIST operation. (There is a similar interaction for route
change processing.) But, I still think it is easiest to make this a 
matter of (static) NSLP policy.

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

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