Subject: [NSIS] GIST Q/D-mode issue

From: Lauri J T Liuhto <[email-masked]>
Date: Mon, 8 Sep 2008 10:04:28 +0300 (EEST)

Hi all,

 First a very short summary of the Q/D-mode issue of NTLPv16 Nuutti
 Varis found in July:

        It seems that it is impossible to differentiate Q-mode and
        D-mode Data messages in a middlebox if Data message is sent
        with GIST Common Header S-flag set.
 
 A more detailed example of this issue is attached to the end of this
 message.

 The issue was briefly discussed at Dublin, and it seems that we have
 at least two different solutions to the issue:

 1) Add a "Q" flag to the GIST Common Header, that would be set
    whenever the message is a Q-mode message.
    + Closely resembles RAO in UDP payload
    + Should be easy to fit in the spec
    - Existing implementations need changes
    - If done, only four free bits remain in GCH
    
 2) Use different port for D-mode messages.
    + Scarce GCH flag reserve not used
    - Bigger changes to spec
    - Possible NAT/Firewall issues
    - Existing implementations need more complex changes

 Best Regards,
 Lauri

  Flow                                Flow
Source                           Destination
  A --------- B --------- C --------- D
  ^===========^=======================^    (Peering relationships)

  ==============[Downstream]==========>

Scenario:
* A, B, C, D GIST nodes with NSLP1
* NSLP1 in A, B and D form peering relationships (A <-> B, B <-> D)
* NSLP1 in C refuses to peer with B

Case #1, Q-mode Data message from B towards D, w/o source signaling:
--------------------------------------------------------------------
B: Send GIST Message #1: 
	Q-mode Data, GCH S=0, MagicNumber, NSLPID
	UDPDst: 4
	 IPSrc: A  IPDst: D
	MRISrc: A MRIDst: D

C: Intercepts GIST Message #1
	UDPDst 4 -> MagicNumber, NSLPID
	    => D- or Q-mode
	S=0 && IPSrc A == MRISrc A && IPDst D == MRIDst D
	    => Q-mode

Case #2, Q-mode Data message from B towards D, w/  source signaling:
--------------------------------------------------------------------
B: Send GIST Message #2:
	Q-mode Data, GCH S=1, MagicNumber, NSLPID
	UDPDst: 4
	 IPSrc: B  IPDst: D
	MRISrc: A MRIDst: D

C: Intercepts GIST Message #2:
	UDPDst 4 -> MagicNumber, NSLPID
	    => D- or Q-mode
	S=1 (&& IPSrc B != MRISrc A && IPDst D == MRIDst D)
	    => Cannot derive D- or Q-mode from IP/MRI info
	    => ?-mode (discard NSLPData or deliver to NSLP?)

Case #3, D-mode Data message from B towards D, w/  source signaling:
--------------------------------------------------------------------
B: Send GIST Message #3
	D-mode Data, GCH S=1, MagicNumber, NSLPID
	UDPDst: 4
	 IPSrc: B  IPDst: D
	MRISrc: A MRIDst: D

C: Intercepts GIST Message #3
	UDPDst 4 -> MagicNumber, NSLPID
	    => D- or Q-mode
	S=1
	    => Cannot derive D- or Q- mode from IP/MRI info
	    => ?-mode (discard NSLPData or deliver to NSLP?)

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

---

From: Roland Bless <[email-masked]>
Date: Wed, 10 Sep 2008 13:14:50 +0200

Hi Lauri,

good that you are coming back on this issue, since I was also
a little bit confused by the proposal to use a new port for the
issue.

>     + Should be easy to fit in the spec
      + does not use another different well-known port number

>     - Existing implementations need more complex changes
      - requires using a different well-known port number

As an implementer I'm much in favor of solution 1):
requires only a few code changes and produces less error
cases, since in the using a different port case other
messages may arrive on the new port as well etc.
Listening on two different ports simultaneously for messages
also requires more system resources and probably major code changes
compared to 1).

I'd like to propose a different option 3): why not use a new message
type for stateless DATA messages? From the internal protocol logic
this would also be easy to implement as a Q-flag, since this type
of DATA message needs a special handling, but it avoids
wasting the flag bit.

Regards,
 Roland

---

From: Roland Bless <[email-masked]>
Date: Wed, 10 Sep 2008 17:20:28 +0200

Hi Lauri and all,

> of DATA message needs a special handling, but it avoids

Max Laier proposed option 4):
use a different magic number for Q-Mode and D-Mode messages.
Any opinions?

Regards,
 Roland

---

From: "Hancock, Robert" <[email-masked]>
Date: Wed, 10 Sep 2008 16:53:48 +0100

hi all,

first, a couple of general points:

- at the conceptual level, i think we should distinguish 
between (a) whether a message is sent in Q- or D-mode, and
(b) whether a message has to be interpreted when received 
in the absence of routing state. in the current spec, either
of these classify messages the same way, but the concepts 
are distinct: (a) is about sender behaviour [mainly, formatting
the message to follow a data path] and (b) is about
receiver behaviour [knowing how to decode what you get].

The overall issue comes up in the NAT traversal case, and
the point (I think) is that the NAT has to do special 
special processing for messages received without prior
routing state.

- this actually exposes a flaw in the previous spec: it was
never supposed to matter to a receiver whether a message
was received in Q- or D-mode, it only mattered to the
sender. (The receiver only cared about the message type.)
The fact that it was possible to tell the difference from
the presence of the RAO was a design artifact (the RAO was
supposed to assist message interception, not change the
semantics of the message.)
Taking into account the conceptual distinctions above, it
is still the case that it shouldn't matter to the 
receiver whether a message was in Q- or D-mode, but it does
matter whether routing state is supposed to be used in
interpreting it.

after that rather long digression, some more detailed points
below:

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Roland Bless
> Sent: 10 September 2008 12:15
> To: Lauri J T Liuhto
> Cc: [email-masked]
> Subject: Re: [NSIS] GIST Q/D-mode issue
> 
> Hi Lauri,
> 
yep
> >     + Should be easy to fit in the spec
yep
>       + does not use another different well-known port number
yes-ish (see below)
> >     - Existing implementations need changes
yep
> >     - If done, only four free bits remain in GCH
true (not a huge problem, but see anyway below).

> >     + Scarce GCH flag reserve not used
true
> >     - Bigger changes to spec
yes - in particular, is it a fixed or negotiated port
> >     - Possible NAT/Firewall issues
yes in either case (bigger issues if negotiated)
> >     - Existing implementations need more complex changes
yes
>       - requires using a different well-known port number
it doesn't necessary need to be well-known, just registered
with IANA. (it could even be dynamic if the port is
advertised by the receiver, but that is also more complicated.)
> of DATA message needs a special handling, but it avoids

this is half attractive for saving the flag bit. however, there is
an issue about extensibility: what if later on another message type
turns up which also needs to be processed by the NAT in the same
way - the NAT implementations need to have a list of message
types to care about, and that list might extend. 

but there's another way of saying the same thing: divide the message
types into two classes, those to be intercepted by NATs and those
which are not. distinguish them by the high-bit in the message 
type field. (it reduces the number of distinct message types from
256 to 128, but that seems not impossible.) obviously, this is the
same as just putting the hypothetical Q-flag in a different place
in the header (and calling it something else.)

> use a different magic number for Q-Mode and D-Mode messages.

i don't really like this. i have generated the appropriate
random number (4d62 8fa0), but it still seems like a hack.
and the same issues about extensibility apply.

when i first analysed this problem, i couldn't find a better
solution than the Q-flag or something like it: in other words,
you have to change the message formats. within the design
space of format changes, my favourite is still option (1), or
modified option (3) if flag bit space exhaustion seems like
a problem.

robert h.

---

From: Max Laier <[email-masked]>
Date: Wed, 10 Sep 2008 18:32:15 +0200

> receiver behaviour [knowing how to decode what you get].
...
> and the same issues about extensibility apply.

I agree and after reading the above realize that my idea would better serve as 
a solution for your point (b) above.  Without the RAO as a simple indication 
when to break the forwarding fast path and hand the packet up the stack for 
more careful inspection it can get really expensive - i.e. you have to hand 
every single D-mode packet all the way up to userland just to figure out that 
you are not interested.  If we were to use a magic number to differentiate 
case (b) it becomes much simpler to perform the interception decision at a 
lower level (e.g. with a bpf filter rule or the like).

-- 
/"\  Best regards,                      | [email-masked]
\ /  Max Laier                          | ICQ #67774661
 X   http://pf4freebsd.love2party.net/  | mlaier@EFnet
/ \  ASCII Ribbon Campaign              | Against HTML Mail and News
_______________________________________________
nsis mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/nsis

---

From: Jukka MJ Manner <[email-masked]>
Date: Wed, 10 Sep 2008 22:56:05 +0300 (EEST)

Hi all,

I also tend to like the "Option 1: Q-flag". It is a rather simple, yet 
clear, way to solve the problem. I don't see that using one more bit from 
the GHC is really that problematic.

Jukka

---

From: Roland Bless <[email-masked]>
Date: Thu, 11 Sep 2008 09:37:52 +0200

Hi Robert,

thanks for elaborating this. Some more comments below.

> receiver behaviour [knowing how to decode what you get].

That's exactly true, nice and clear distinction that I had
in mind, but I wasn't able to express it so clearly :-)
For Q-mode Data messages the concepts were a little bit
intermingled since a Data message had to be interpreted differently
if received in Q-mode (as you describe below, too).

> special processing for messages received without prior

Ok.

> semantics of the message.)

Yes, however, if a message came with an RAO, it came via Q-mode
encapsulation and that was what mattered for our case distinction.

> matter whether routing state is supposed to be used in

If I look at our source code we first check whether
a corresponding routing state exists and then check
for the message type. If the Data message came via Q-mode,
we deliver it, if it did not arrive via Q-mode
we have an error condition (e.g, because a Confirm
was lost):
https://projekte.tm.uni-karlsruhe.de/trac/NSIS/browser/ntlp/trunk/src/ntlp_statemodule_main.cpp#L703
So Q-mode/D-mode distinction is in this case important
to decide whether the Data message has to be interpreted although
no routing state exists. That could also be achieved by the
different message type that I proposed, but I agree with your
counter argument below.

> types to care about, and that list might extend. 

Ok, good point. In that case it is a good reason to do it differently.

> in the header (and calling it something else.)

Yep. I think it is useful to have an explicit indication for
your function (a), i.e., a Q-mode flag in the message, however,
formerly whether a GIST message arrived via Q-mode or D-mode
was not visible in the GIST message itself, only by the outer
encapsulation method. Having a Q-mode flag would now generate
new error conditions to check for, e.g, if Q-mode flag is set
in a C-mode message etc.

> modified option (3) if flag bit space exhaustion seems like

Agreed. The question is, whether there are cases in which
the message does not arrive via Q-mode, but the message has
to be interpreted nevertheless in case of missing routing state.
So this would be a flag exactly for your function (b) from above,
something like a stateLess flag
"if this message arrived and no routing state exists,
it is ok to interpret it nevertheless". However, since this is
allowed for certain message types only we have to check the
particular message type, too. So it is not clear to me, whether
we could actually avoid the above mentioned list of message types
that NATs have to care about.

Regards,
 Roland

---

From: "Robert Hancock" <[email-masked]>
Date: Wed, 17 Sep 2008 11:53:46 +0100

hi,

comments below (mainly at the end). 

short summary: my preference at the moment is to
use the flag bit method, but to put the flag at
the start of the message type field. (saves a bit,
and brings out the relationship between flag and
message type.)

more below ... 

> From: Roland Bless [mailto:[email-masked]] 
> Sent: 11 September 2008 08:38
> To: Hancock, Robert
> Cc: Lauri J T Liuhto; [email-masked]

that's quite right - my point was that you should not have had
to use the RAO to work that out.

> new error conditions to check for, e.g, if Q-mode flag is set

indeed (see also at the end). i think we would have one extra
error, 'invalid Q-flag' causing the message to be dropped.
(I see it as another instance of a formatting error.)

> that NATs have to care about.

there are two points:

- for a NAT, it does the operation on the message based on the
presence of the Q flag only. it doesn't check if that flag was
valid for the message type.

- the end system needs to decide if the Q flag, message type, and
internal state are all consistent. this will require logic changes
if the set of message types changes - but these would be required
at the end system anyway (to cope with a new message).

cheers,

robert h.

---

From: Jukka MJ Manner <[email-masked]>
Date: Mon, 22 Sep 2008 21:27:22 +0300 (EEST)

Dear all,

I'd like people to comment on this thread. This question is the last one 
before getting GIST accepted.

The proposal seems to be the addition of a Q-flag.

If people are fine with this, a short on the note list would be 
appreciated.

Jukka

---

From: Teemu Huovila <[email-masked]>
Date: Mon, 22 Sep 2008 21:37:37 +0300 (EEST)

Hello

> and brings out the relationship between flag and
Roberts reasoning for putting the information in the message field made 
good sense to me. Though I can not say I fully comprehended all the 
implications, which Robert mentioned, of the original issue pertaining to 
NAT boxes. I also endorse the "message type division" option. 

br,
Teemu

-- 
Teemu Huovila

---

From: Nuutti Varis <[email-masked]>
Date: Mon, 22 Sep 2008 21:46:42 +0300

Greetings,

> NAT boxes. I also endorse the "message type division" option.

A flag seems the most straightforward solution to the problem from an  
implementation's
point of view, so I also fully support it. Dividing the message type  
space into stateless
and stateful messages seems a good idea from extendability and  
philosophical point of view.

BR, Nuutti

---

From: Roland Bless <[email-masked]>
Date: Mon, 22 Sep 2008 21:35:56 +0200

Hi Jukka and all,

Regards,
 Roland

---

From: Lauri J T Liuhto <[email-masked]>
Date: Tue, 23 Sep 2008 00:07:00 +0300 (EEST)

> >> and brings out the relationship between flag and

 I'm also happy with the solution suggested by Robert.

 Regards,
 Lauri

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Thu, 25 Sep 2008 06:41:15 +0000

Hi all

In the current specification of GIST it is mentioned that the NSLP can
request from GIST to use Q-mode.
When using the Q-flag, I assume that NSLP can then require from GIST to
set/unset the Q-flag.

If the above is right then I am in favour of using the Q-flag!

Best regards,
Georgios

---

From: Lauri J T Liuhto <[email-masked]>
Date: Thu, 25 Sep 2008 12:39:54 +0300 (EEST)

> request from GIST to use Q-mode.

 Do you mean Local Processing hints (see ntlp I.D v16, page 24) or 
something else?

> When using the Q-flag, I assume that NSLP can then require from GIST to

 Q-flag changes only GIST layer - as far as I know, changes to NSLP API 
have not been proposed.

 Best regards,
 Lauri

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Thu, 25 Sep 2008 09:51:54 +0000

Hi Lauri

Yes I mean the Loal Processing hints.
Regarding the NSLP API, if the Q-flag is used then I propose to change the
NSLP API.

Best regards,
Georgios

---

From: Lauri J T Liuhto <[email-masked]>
Date: Thu, 25 Sep 2008 13:05:16 +0300 (EEST)

Hi Georgios,

 Ok.

> Regarding the NSLP API, if the Q-flag is used then I propose to change the

 Adding the Q-flag does not inflict any changes to the NSLP API. Thus, no 
changes have been proposed. As far as I know, adding the Q-flag does not 
change GIST functionality for NSLP developers at all. It just allows GIST 
to work correctly.

 Best regards,
 Lauri

-- 
Lauri Liuhto
[email-masked] -- 040-7009603
_______________________________________________
nsis mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/nsis

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Thu, 25 Sep 2008 10:26:18 +0000

Hi Lauri

Yes, I know that it has not been proposed.
I am now proposing to include this modification into the NSLP API.

Best regards,
Georgios

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 25 Sep 2008 14:29:09 +0200

> I am now proposing to include this modification into the NSLP API.

Why?

I like to remind people that this document has been through IETF last 
call and IESG review. This issues with the Q/D mode indication flag that 
is needs as result of the removal of the requirement to use RAO. It is 
not intended to be a change in functionality.

So unless this is a serious bug I would say that we avoid any changes 
there.

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Färögatan 6                | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------
_______________________________________________
nsis mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/nsis

---

From: "Hancock, Robert" <[email-masked]>
Date: Thu, 25 Sep 2008 17:43:25 +0100

i agree with Magnus :-D

there is no conceptual change to the way the NSLP invokes GIST at
all, nor is there any need for any practical change (that i can 
detect). this is just a GIST message formatting issue - the 
functionality is the same as what it always was (at least, what
it was supposed to have been).

cheers,

r.

> Behalf Of Magnus Westerlund
> Sent: 25 September 2008 13:29
> To: Georgios Karagiannis
> Cc: [email-masked]; Jukka MJ Manner

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Fri, 26 Sep 2008 13:03:56 +0200

Hi Robert

Okay, so the way of how the Q mode is set remains the same!

Then it is okay!

Best regards,
Georgios

> Behalf Of Hancock, Robert
> Sent: donderdag 25 september 2008 18:43
> To: Magnus Westerlund; Georgios Karagiannis
> Cc: Jukka MJ Manner; [email-masked]
> there is no conceptual change to the way the NSLP invokes 
> GIST at all, nor is there any need for any practical change 
> (that i can detect). this is just a GIST message formatting 
> issue - the functionality is the same as what it always was 
> (at least, what it was supposed to have been).
> 
> cheers,
> 
> r.
> 
> > From: [email-masked] [mailto:[email-masked]] 
> On Behalf 
> > Of Magnus Westerlund
> > call and IESG review. This issues with the Q/D mode indication flag 
> > that is needs as result of the removal of the requirement 
> to use RAO. 
> > It is not intended to be a change in functionality.
> >

---

From: Jukka MJ Manner <[email-masked]>
Date: Fri, 26 Sep 2008 19:08:56 +0300 (EEST)

Thanks, Magnus. Well said.

Jukka

On Thu, 25 Sep 2008, Magnus Westerlund wrote:

> I like to remind people that this document has been through IETF last call and
> IESG review. This issues with the Q/D mode indication flag that is needs as
> result of the removal of the requirement to use RAO. It is not intended to be
> a change in functionality.
> 
> So unless this is a serious bug I would say that we avoid any changes there.
> 
> Cheers
> 
> Magnus Westerlund
>