Subject: RE: [NSIS] GIST: NSLP data in QUERY

From: Jukka MJ Manner <[email-masked]>
Date: Wed, 11 Apr 2007 11:04:17 +0300 (EEST)

Hi all,

Some comments below (finally).

On Wed, 28 Mar 2007, Hancock, Robert wrote:

> hi all,
> 
> it's good to keep working through this, because there are several
> subtleties. but i think the current design and API handles nearly 
> everything i have seen mentioned so far. the main points are more NSLP 
> (or, in fact, signalling application) design issues rather than GIST 
> issues.
> 
> specifically:
> 
> - a signalling application has to define the algorithm that it uses
> when deciding whether to peer. if the algorithm is 'always true'
> then there is nothing else to do. if the algorithm depends on
> information
> beyond the information in the MRI/SID/NSLPID then this information has
> to be defined as part of the NSLP specification.

Yes, it does. Yet, the problem is, how to get this "peering data (PD)" to 
the next NSLP hop.

> 
> - almost by definition, this information cannot need security 
> protection from GIST, because that is only possible after peering.
> (if security protection is needed, that would have to be done in 
> the NLSP itself; or else one needs something much more complex,
> probably involving multiple NSLPIDs.)

Yes, exactly. This PD is sent in unsecure mode, and the NSLP designer must 
be aware of that.

> 
> - so far as reliability is concerned, again this is more a matter of
> NSLP design. if one is probing for a peer, the response from the peer
> indicates that the original message was delivered. if you get no
> response within some timeout, there is no peer to respond. the NSLP
> needs to make sure that it doesn't retransmit within the validity
> time it provides with the message (since the GIST level can retransmit
> Queries during this period). the more important thing to note is that
> the NSLP payload can be delivered multiple times, so it needs to be
> idempotent.

Yes.

> 
> - the API already provides the hooks to express reliability and
> security requirements. so, for a probing message, you just leave these
> unset.

Yes.

> 
> - and the API also allows the NSLP to be aware of the routing status:
> at the querying node the fact that there is no SII means that no
> routing state exists; at the responding node, the fact that this is
> done with the routing state check flag set in RecvMessage means that
> this decision is being made.
> 
> - another issue is how the NSLP influences the refresh of this
> conditional peering. GIST handles making sure that the routing state
> as defined by the MRM is up to date, but if there is NSLP-dependent
> information that should be used in the peering decision that will not
> be taken care of. OTOH, the timescales over which MRM-related state
> and NSLP-related state might need to be checked can be quite
> independent,
> so I don't think there is a need to extend the definition of normal GIST
> routing state refresh to cover this. if the NSLP really does want to
> check that the NSLP-dependent peering is still valid, it can always
> force a refresh with the InvalidateState call. This will start a 
> refresh at some point in the future.
> 
> - what is slightly messy is that the NSLP would have to do Invalidate
> and then SendMessage to provide the NSLP data for the Query payload,
> so there are API-internal race conditions. One could regard this as
> just an implementation issue; another possibility would be to extend
> Invalidate with the option to provide an NSLP payload and associated
> fields (excluding transfer attributes, since they must be null).

I think you misunderstood our idea. The point is that the SendMessage 
primitive would carry an additional PD object. This PD data is included in 
the QUERY and used on the next hop to make a decision whether to peer, or 
forward the QUERY downstream (and forget about it). Retransmission is set 
by the signaling initiator.

The scenario is the following:

[N1: Initiator, NSLP-Xa] --- [N2: NSLP_Xb] --- [N3: NSLP_Xa] 

We have three nodes, all running NSLP-X, but two are running version "a" 
of that NSLP, and one is running version "b". Now N1 wants to send a 
message to its next hop NSLP-Xa peer in a reliable way. What would happen:

1. N1 sends a GIST QUERY and includes a PD="a"
2. N2 receives the QUERY, has the NSLP-X running, but the PD indicates 
   "a".
3. Since N2 is not running "a", it forwards the QUERY downstream towards 
   N3, and forgets it never saw the message
4. N3 receives the QUERY, has the NSLP-X running and PD also indicates 
   "a".
5. N3 thus decides that it wants to peer with N1, and sets up the reliable 
   MA with N1
6. N2 in the middle just routes messages between the peers N1 and N3

_Without_ such a PD in the initial QUERY, N1 would need to set up an MA 
with N2, send the NSLP data to N2, which then needs to set a separate MA 
with N3 to send that data forward (since it does not run the requested 
NSLP-X version "a").

Any other solution, where we need some NSLP leve tricks gets really messy. 
We have gone through various scenarios, and the possibility to include 
this unsecured and idempotent peering data in a QUERY (besides the NSLP ID 
and MRI) is a very elegant and simple mechanism.

Cheers,
Jukka

> 
> i created
> http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/issue213
> to cover this specific point.
> 
> r.
> 
> > -----Original Message-----
> > From: Jukka MJ Manner [mailto:[email-masked]] 
> > Sent: 28 March 2007 10:32
> > To: Roland Bless
> > Cc: NSIS Working Group; Hancock, Robert
> > Subject: Re: [NSIS] GIST: NSLP data in QUERY
> > 
> > 
> > Hi,
> > Yes, good point.
> > 
> > Yet... on the other hand, if you don't get a QUERY through, 
> > then you won't get to set up an MA anyway, so basically the 
> > extra data is also sent in a reliable way. But it is not secured.
> > 
> > Jukka
> > 
> > On Wed, 28 Mar 2007, Roland Bless wrote:
> > 
> > > Hi,
> > > 
> > > Jukka MJ Manner wrote:
> > > > On Fri, 23 Mar 2007, Roland Bless wrote:
> > > >> Jukka MJ Manner wrote:
> > > >>> I've been thinking about how GIST uses the Q-mode. If 
> > an NSLP asks 
> > > >>> for reliable or secure mode, GIST will send the query 
> > without NSLP payload.
> > > >>> Yet, would it be possible to still allow an NSLP to include 
> > > >>> information carried in the query.
> > > >> If the semantics for this data is different, yes.
> > > > 
> > > > It can be different, or copies of certain NSLP objects. 
> > GIST doesn't 
> > > > need to care anyway, it's just a feature of NSLPs.
> > > 
> > > I meant the transport semantics, e.g. reliable/unreliable 
> > transport of 
> > > this NSLP data. So the NSLP would transfer a first data chunk 
> > > unreliably/unsecured in the Query and after the handshake then 
> > > reliable...
> > > So this first data chunk has different semantics within 
> > NSLP than the 
> > > other NSLP data that follow and this must be made 
> > explicitly visible 
> > > at the API. That was my point.
> > > 
> > > Regards,
> > >  Roland
> > > 
> > > 
> > 
> 

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

---

From: Lauri J T Liuhto <[email-masked]>
Date: Thu, 12 Apr 2007 10:57:33 +0300

Hi all,

 I think that conditional peering can not be (at least not elegantly)
 done without "early data". Inclusion of NSLP Data into
 InvalidRoutingState(..)  API call (Appendix B.6, see also
 http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/issue213)
 in the gist draft version -13 did not help with conditional peering,
 at least not in all scenarios.

 I think that the modifications to GIST are not too big if we want to
 support NSLP data ("early data") also with queries for secure and/or
 reliable MAs.

 If NSLP is sending a query with unsecured/unreliable transfer
 attributes, no changes are needed.

 In the case of NSLP sending a query with secure and/or reliable
 transfer attributes, we need to modify the GIST specification a
 bit. We need to point out, that "early data" is _never_
 secure/reliable even if NSLP requested secure/reliable transport. In
 other words: NSLP *should be able to* send early data if it really
 knows what it is doing.

 There are several sections needing modifications to support "early
 data", but I think that at least most of the modifications are quite
 small.

 My opinion is, that a new TLV object, similar to the NSLP Data Object
 is needed for "early data". This is to make a clear distinction
 between NSLP Data and "early data", because their security and
 reliability attributes differ.
 
 Some modifications are also needed to the NSLP API:

 SendMessage(..) API call needs two new parameters, for example
 'Early-NSLP-Data' and 'Early-NSLP-Data-Size'. A NSLP making use of
 "early data" should always include it into SendMessage(..) call,
 because the NSLP usually can not know whether a GIST Data or Query is
 going to be sent.

 For RecvMessage(..) call we have many alternative ways to get things
 working, but I think that the most clear approach is similar to
 SendMessage(...), just add two parameters 'Early-NSLP-Data-Size' and
 'Early-NSLP-Data'.

 Best Regards,
 Lauri

On Wednesday 11 April 2007 11:04, Jukka MJ Manner wrote:
> > everything i have seen mentioned so far. the main points are more
> > NSLP (or, in fact, signalling application) design issues rather
> > than GIST issues.
> >
> > specifically:
> >
> > beyond the information in the MRI/SID/NSLPID then this information
> > has to be defined as part of the NSLP specification.
>
> Yes, it does. Yet, the problem is, how to get this "peering data
> (PD)" to the next NSLP hop.
>
> Yes, exactly. This PD is sent in unsecure mode, and the NSLP designer
> must be aware of that.
>
> > - so far as reliability is concerned, again this is more a matter
> > of NSLP design. if one is probing for a peer, the response from the
> > peer indicates that the original message was delivered. if you get
> > no response within some timeout, there is no peer to respond. the
> > NSLP needs to make sure that it doesn't retransmit within the
> > validity time it provides with the message (since the GIST level
> > can retransmit Queries during this period). the more important
> > thing to note is that the NSLP payload can be delivered multiple
> > times, so it needs to be idempotent.
>
> Yes.
>
> > security requirements. so, for a probing message, you just leave
> > these unset.
>
> Yes.
>
> > - and the API also allows the NSLP to be aware of the routing
> > status: at the querying node the fact that there is no SII means
> > that no routing state exists; at the responding node, the fact that
> > this is done with the routing state check flag set in RecvMessage
> > means that this decision is being made.
> >
> > conditional peering. GIST handles making sure that the routing
> > state as defined by the MRM is up to date, but if there is
> > NSLP-dependent information that should be used in the peering
> > decision that will not be taken care of. OTOH, the timescales over
> > which MRM-related state and NSLP-related state might need to be
> > checked can be quite independent,
> > so I don't think there is a need to extend the definition of normal
> > GIST routing state refresh to cover this. if the NSLP really does
> > want to check that the NSLP-dependent peering is still valid, it
> > can always force a refresh with the InvalidateState call. This will
> > start a refresh at some point in the future.
> >
> > - what is slightly messy is that the NSLP would have to do
> > Invalidate and then SendMessage to provide the NSLP data for the
> > Query payload, so there are API-internal race conditions. One could
> > regard this as just an implementation issue; another possibility
> > would be to extend Invalidate with the option to provide an NSLP
> > payload and associated fields (excluding transfer attributes, since
> > they must be null).
>
> primitive would carry an additional PD object. This PD data is
> included in the QUERY and used on the next hop to make a decision
> whether to peer, or forward the QUERY downstream (and forget about
> it). Retransmission is set by the signaling initiator.
>
> We have three nodes, all running NSLP-X, but two are running version
> "a" of that NSLP, and one is running version "b". Now N1 wants to
> send a message to its next hop NSLP-Xa peer in a reliable way. What
> would happen:
>
> 2. N2 receives the QUERY, has the NSLP-X running, but the PD
> indicates "a".
> 3. Since N2 is not running "a", it forwards the QUERY downstream
> towards N3, and forgets it never saw the message
> 4. N3 receives the QUERY, has the NSLP-X running and PD also
> indicates "a".
> 5. N3 thus decides that it wants to peer with N1, and sets up the
> reliable MA with N1
> _Without_ such a PD in the initial QUERY, N1 would need to set up an
> MA with N2, send the NSLP data to N2, which then needs to set a
> separate MA with N3 to send that data forward (since it does not run
> the requested NSLP-X version "a").
>
> Any other solution, where we need some NSLP leve tricks gets really
> messy. We have gone through various scenarios, and the possibility to
> include this unsecured and idempotent peering data in a QUERY
> (besides the NSLP ID and MRI) is a very elegant and simple mechanism.
>
> Cheers,
> Jukka
>
> > i created
> > http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/issue21
> >3 to cover this specific point.
> >
> > r.
> >

---

From: "Hancock, Robert" <[email-masked]>
Date: Thu, 19 Apr 2007 16:53:34 +0100

Jukka, Lauri,

[replying to Jukka's mail since that has the example that I need
to react to, but hopefully covering both your points]:

[snipping stuff we all agree on]

> > independent, so I don't think there is a need to extend the 
> definition 
> > of normal GIST routing state refresh to cover this. if the 
> NSLP really 
> > does want to check that the NSLP-dependent peering is still 
> valid, it 
> Invalidate 
> I think you misunderstood our idea. The point is that the 
> SendMessage primitive would carry an additional PD object. 
> This PD data is included in the QUERY and used on the next 
> hop to make a decision whether to peer, or forward the QUERY 
> downstream (and forget about it). Retransmission is set by 
> the signaling initiator.

i don't believe there is a need for an additional object type
or API extension for this. the NSLP knows whether routing state
exists or not. If it does, the peering has already taken place
and it is too late to change it's mind. If it does not, then
the NSLP knows that any data it provides without reliability/
security transfer attributes can be used in the conditional 
peering decision. (There are two cases: when there has never
been any routing state, and when the NSLP has just invalidated
it.)

> of that NSLP, and one is running version "b". Now N1 wants to 
> send a message to its next hop NSLP-Xa peer in a reliable 
> way. What would happen:
> 
> indicates 
>    N3, and forgets it never saw the message 4. N3 receives 
> the QUERY, has the NSLP-X running and PD also indicates 
>    "a".
> _Without_ such a PD in the initial QUERY, N1 would need to 
> set up an MA with N2, send the NSLP data to N2, which then 
> needs to set a separate MA with N3 to send that data forward 
> (since it does not run the requested NSLP-X version "a").

The problem with this example is that it is unclear exactly
how many signalling applications and peering relationships there
really are in existence. If we follow the example through, it
would seem that sometimes N1 is talking to N2 and sometimes to 
N3, depending on the data transfer characteristics involved. 
But that is bad news: does N1 now have two downstream peers for
the same signalling application? or is it swapping between the
two (like a route change)?

The way I see it is that either N1 is peered with N2 or with N3.
If N1 wants to bypass N2 then it should peer directly with N3, 
and it can do this by including the PD as normal (unsecured, 
unreliable) data in messages it sends when there is no routing
state. That is, the existing spec already allows this behaviour:
for the sending NSLP as just noted, and for the receiving NSLP
because there is the Routing-State-Check boolean in the RecvMessage
API call and the bypass processing described in 4.3.2. Note that
just adding additional PD objects to the RecvMessage API call
is *not* sufficient: GIST *has* to enforce the correctness of the
cookie/MRI/TTL/GHC processing, and so conditional forwarding
*cannot* be modelled simply as a RecvMessage to the NSLP followed
by a SendMesssage to propagate the data.

If N1 wants to talk to N2 sometimes and N3 other times, then
there are two choices:
- define a proxy mode for the NSLP (so N2 can forward data
transparently)
- split X into two separate NSLPs with different NSLPIDs, and peer
for each one separately.

Note finally that if we later come across other conditional peering
cases where the conditionality does not fit nicely with an NSLP-level
request/reply exchange (which is the implicit assumption so far),
then the existing GIST extensibility mechansisms can already handle
it within the current protocol design (specifically, I would define
a new MRM which included the input to the conditional peering 
decision in the MRI).

hope this makes sense,

robert h.

> We have gone through various scenarios, and the possibility 
> to include this unsecured and idempotent peering data in a 
> QUERY (besides the NSLP ID and MRI) is a very elegant and 
> simple mechanism.
> 
> Cheers,
> Jukka
> 
> > 
> > i created
> > > Yet... on the other hand, if you don't get a QUERY 
> through, then you 
> > > won't get to set up an MA anyway, so basically the extra data is 
> > > also sent in a reliable way. But it is not secured.
> > > 
> > > Jukka
> > >

---

From: Jukka MJ Manner <[email-masked]>
Date: Fri, 20 Apr 2007 12:06:27 +0300 (EEST)

Hi Rob,

Some comments below.

> been any routing state, and when the NSLP has just invalidated

Yes, true for the existing state. Yet, if I want to set up a secure and/or 
reliable MA, then I can't get additional peering data through, until the 
MA is set up. This wastes resouces and adds delay, since I need to set up 
an MA first to the next NSLP peer, and then see if it really should be my 
next peer, or not.

> two (like a route change)?

If N1 has both "a" and "b" versions, then it may have MAs with both N2 and 
N3. The data transfer attributes do not matter, only the peering data 
specifies who we are talking with. And N1 then has two separate sessions, 
one with N2 and one with N3.

> by a SendMesssage to propagate the data.

Right. If you want to set up a C-mode MA, then this additional data is not 
available currently in the spec.

> - define a proxy mode for the NSLP (so N2 can forward data

So, you need
- to set an MA first between N1 and N2, then 
- N2 gets the NSLP,
- has to process it to figure out it can't really do nothing with, 
- initiate the setting up of a new MA to next peer
- all communications with N1 and N3 would then always go though N2.

Instead, N1 sends a QUERY that has enough information for N2 to figure out 
it should send the QUERY forward, and forget about it.

> - split X into two separate NSLPs with different NSLPIDs, and peer

What if you have a million different combinations of peering data? Ask a 
million NSLP IDs from IANA?

> a new MRM which included the input to the conditional peering 

Right, so instead of making a generic peering data possible, we could 
define a new MRM where the MRI includes additional fields. Sounds good to 
me. And seems to solve our problem.

A related question: what does a GIST node do, if it encounters an unknown 
MRM? I guess the node drops the message, since it doesn't know how to 
route it.

Thanks for the feedback,
Jukka