Subject: [NSIS] GIST D-mode encapsulation and transparency issues

From: "Hancock, Robert" <[email-masked]>
Date: Mon, 12 Feb 2007 16:23:08 -0000

Hi,

One of a cluster of related questions raised about GIST is the extent to
which it modifies the rules for packet processing within the network
compared to what would be the case today. There are actually two
complementary aspects (note that both apply only to Q-mode, since all
other GIST traffic is normally encapsulated point-to-point IP
datagrams):
a) if hosts or routers are doing things with options at the IP level or
otherwise changing the packet e.g. with AH or ESP (IPsec) processing,
what does this do to GIST?
b) do the GIST interception rules prevent it harming traffic that is
nothing to do with GIST in the first place?

Below is some text addressing these topics. The important question is at
the end (so please read all the way ...)

Note: The RAO discussion is a related topic (not covered fully here,
except in so far as it matters).

Both these questions are related in that they are best answered by a
more precise description of how GIST intercepts and processes Q-mode
messages. My belief is that the correct set of rules is as follows.

For IPv4, for a Q-mode packet:
the IP-Protocol field MUST = UDP
the destination port for UDP MUST = GIST
there MAY be arbitrary IP options
the RAO MUST be included by the sender, but a node MAY decide to
intercept packets purely on protocol/port number analysis and so
intercept a packet even if the RAO is not present. (This is left open
this way to allow the possibility that to mitigate IP option problems
with firewalls, we might allow Q-mode without the RAO in the future.
This is part of the separate discussion on RAO handling in general.)

For IPv6, for a Q-mode packet:
the next-header field MUST either be UDP, or some combination of
routing/hop-by-hop options/destination options followed by UDP
the destination port for UDP MUST = GIST
the RAO MUST be included by the sender, and it is RECOMMENDED that a
node bases its initial interception decision purely on the presence of
the RAO without analysing the header chain.

for either IP version:

packets not matching the above criteria MUST be transparently forwarded
(at a router) or locally delivered as normal traffic (at a host). No
other packets are GIST packets; this includes IP-in-IP tunnelled
packets, other tunnelled packets (tunnel mode AH/ESP), or packets which
have undergone some additional transport layer processing (transport
mode AH/ESP). If IP output processing at a node causes such additional
encapsulations to be added to a GIST Q-mode packet, this packet will not
be identified as GIST until the encapsulation is terminated. If the node
wishes to signal for data over the network region where the
encapsulation applies, it MUST generate additional signalling with an
MRI matching the encapsulated traffic and outbound GIST Q-mode message
MUST bypass the encapsulation processing.

in general, IP options processing is intended to be carried out
independently of GIST processing. On packets transmitted by GIST, IP
options MAY be added according to node-local policies on outgoing IP
data. On packets forwarded by GIST (without NSLP processing), IP options
MUST be processed as for a normally forwarded IP packet. 

On packets locally delievered to the NSLP, the IP options MAY be passed
to the NSLP and equivalent options used on subsequently generated
outgoing Q-mode packets. In this case, routing related options on SHOULD
be processed identically as for a normally forwarded IP packet.

Personally I think the above is all fairly self-explanatory, but if
people want to suggest alternative text (or ask for clarifications) they
are welcome to do so.

The remaining question, following all this detail, is how to handle the
possibility that GIST intercepts traffic which isn't really GIST
traffic. According to the above rules, this can only happen if someone
generates traffic to the GIST UDP port, which will be a reserved ("well
known") port. There are two possible approaches here:

- state that people shouldn't use a well-known port unless it has been
allocated through IANA. if they do, and their traffic gets intercepted,
that is their bad luck.

- state additional rules for GIST interception; this would have to be
some additional fact about the UDP payload which other 'random' traffic
would not have. [Note: it's better not to rely on the presence of the
RAO for reasons noted above.] The most robust technique here would seem
to be to require a magic 32-bit number at the start of the UDP payload,
and bypass packets which did not have it. This is done in some other
protocols (e.g. BGP, PPP). I just harvested 32 bits of entropy from a
linux server (0x4e04 bda5) which would seem eminently suitable for this
purpose.

What do people feel about this choice? At the moment, I would prefer to
do things the first way, but the second is not much effort (just a
change to the Q-mode encapsulation definition in section 5.3.2). 

robert h.

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

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Wed, 14 Feb 2007 09:57:14 +0100

Hi Robert

Before answering your current question I would like to know 
what you mean by the following, and in particular, the sentence related by 
the separate discussion on RAO handling in general?
> (This is left open this way to 
> allow the possibility that to mitigate IP option problems 

Do you expect that the way of how GIST handles RAO will be modified?

Best regards,
Georgios

> -----Original Message-----
> From: Hancock, Robert [mailto:[email-masked]] 
> Sent: maandag 12 februari 2007 17:23
> To: [email-masked]
> Subject: [NSIS] GIST D-mode encapsulation and transparency issues
> 
> Hi,
> 
> One of a cluster of related questions raised about GIST is 
> the extent to which it modifies the rules for packet 
> processing within the network compared to what would be the 
> case today. There are actually two complementary aspects 
> (note that both apply only to Q-mode, since all other GIST 
> traffic is normally encapsulated point-to-point IP
> datagrams):
> a) if hosts or routers are doing things with options at the 
> IP level or otherwise changing the packet e.g. with AH or ESP 
> (IPsec) processing, what does this do to GIST?
> b) do the GIST interception rules prevent it harming traffic 
> that is nothing to do with GIST in the first place?
> 
> Below is some text addressing these topics. The important 
> question is at the end (so please read all the way ...)
> 
> Note: The RAO discussion is a related topic (not covered 
> fully here, except in so far as it matters).
> 
> Both these questions are related in that they are best 
> answered by a more precise description of how GIST intercepts 
> and processes Q-mode messages. My belief is that the correct 
> set of rules is as follows.
> 
> the destination port for UDP MUST = GIST there MAY be 
> arbitrary IP options the RAO MUST be included by the sender, 
> but a node MAY decide to intercept packets purely on 
> protocol/port number analysis and so intercept a packet even 
> if the RAO is not present. (This is left open this way to 
> allow the possibility that to mitigate IP option problems 
> the next-header field MUST either be UDP, or some combination 
> of routing/hop-by-hop options/destination options followed by 
> UDP the destination port for UDP MUST = GIST the RAO MUST be 
> included by the sender, and it is RECOMMENDED that a node 
> bases its initial interception decision purely on the 
> presence of the RAO without analysing the header chain.
> 
> for either IP version:
> 
> packets not matching the above criteria MUST be transparently 
> forwarded (at a router) or locally delivered as normal 
> traffic (at a host). No other packets are GIST packets; this 
> includes IP-in-IP tunnelled packets, other tunnelled packets 
> (tunnel mode AH/ESP), or packets which have undergone some 
> additional transport layer processing (transport mode 
> AH/ESP). If IP output processing at a node causes such 
> additional encapsulations to be added to a GIST Q-mode 
> packet, this packet will not be identified as GIST until the 
> encapsulation is terminated. If the node wishes to signal for 
> data over the network region where the encapsulation applies, 
> it MUST generate additional signalling with an MRI matching 
> the encapsulated traffic and outbound GIST Q-mode message 
> in general, IP options processing is intended to be carried 
> out independently of GIST processing. On packets transmitted 
> by GIST, IP options MAY be added according to node-local 
> policies on outgoing IP data. On packets forwarded by GIST 
> (without NSLP processing), IP options MUST be processed as 
> for a normally forwarded IP packet. 
> 
> On packets locally delievered to the NSLP, the IP options MAY 
> be passed to the NSLP and equivalent options used on 
> subsequently generated outgoing Q-mode packets. In this case, 
> routing related options on SHOULD be processed identically as 
> for a normally forwarded IP packet.
> 
> Personally I think the above is all fairly self-explanatory, 
> but if people want to suggest alternative text (or ask for 
> clarifications) they are welcome to do so.
> 
> The remaining question, following all this detail, is how to 
> handle the possibility that GIST intercepts traffic which 
> isn't really GIST traffic. According to the above rules, this 
> can only happen if someone generates traffic to the GIST UDP 
> port, which will be a reserved ("well
> - state that people shouldn't use a well-known port unless it 
> has been allocated through IANA. if they do, and their 
> traffic gets intercepted, that is their bad luck.
> 
> - state additional rules for GIST interception; this would 
> have to be some additional fact about the UDP payload which 
> other 'random' traffic would not have. [Note: it's better not 
> to rely on the presence of the RAO for reasons noted above.] 
> The most robust technique here would seem to be to require a 
> magic 32-bit number at the start of the UDP payload, and 
> bypass packets which did not have it. This is done in some 
> other protocols (e.g. BGP, PPP). I just harvested 32 bits of 
> entropy from a linux server (0x4e04 bda5) which would seem 
> eminently suitable for this purpose.
> 
> What do people feel about this choice? At the moment, I would 
> prefer to do things the first way, but the second is not much 
> effort (just a change to the Q-mode encapsulation definition 
> in section 5.3.2). 
> 
> robert h.
>

---

From: "Hancock, Robert" <[email-masked]>
Date: Wed, 14 Feb 2007 09:31:24 -0000

hi 

> From: Georgios Karagiannis [mailto:[email-masked]] 
> Hi Robert
> 
> what you mean by the following, and in particular, the 
> sentence related by the separate discussion on RAO handling 
> in general?
> > allow the possibility that to mitigate IP option problems with 
> > firewalls, we might allow Q-mode without the RAO in the future.

well, the point of keeping that discussion separate was ... to 
keep it separate. the short answer is that there will be some
text to handle legacy nodes and deployment issues, but nothing 
that should affect your answer to the actual question posed.

r.

---

From: Ruud Klaver <[email-masked]>
Date: Wed, 14 Feb 2007 17:11:31 +0100

Hi,

> This is part of the separate discussion on RAO handling in general.)

In reading the current specs, the RAO in Q-Mode messages seems 
mandatory, although it is not stated that explicitly. Following that it 
seems logical that a node actually MUST NOT decide to intercept packets 
purely on protocol/port number, exactly for the reason of inadvertedly 
capturing non-GIST traffic. Indeed, some parts of the GIST 
implementation I did are built on the assumption that Q-Mode messages 
contain a RAO value.

> people want to suggest alternative text (or ask for clarifications) they

Yes, it the rest makes sense.

> change to the Q-mode encapsulation definition in section 5.3.2). 

Continuing what I said above, if a Q-Mode message always carries a RAO, 
there are actually two criteria to distinguish GIST traffic from other 
traffic, i.e. the RAO option and the destination UDP port. This to me 
seems sufficient.

So, this question only becomes relevant when you cannot rely on the 
presence of the RAO. This however I feel would be a change from the 
current specification. You indicate that either removing the RAO field 
or making it optional would be a separate discussion, but it is a 
discussion that should precede this one. Until that time it's not much 
of a problem.

Best regards,
Ruud Klaver

---

From: "Hancock, Robert" <[email-masked]>
Date: Thu, 15 Feb 2007 12:55:14 -0000

hi, 

> From: Ruud Klaver [mailto:[email-masked]] 
> Sent: 14 February 2007 16:12
> To: [email-masked]
> Subject: Re: [NSIS] GIST D-mode encapsulation and transparency issues
> 
> Hi,
> 
> Hancock, Robert wrote:
> > Hi,
> > 
> the extent 
> > to which it modifies the rules for packet processing within the 
> > network compared to what would be the case today. There are 
> actually 
> > two complementary aspects (note that both apply only to 
> Q-mode, since 
> > all other GIST traffic is normally encapsulated point-to-point IP
> > datagrams):
> IP level 
> > or otherwise changing the packet e.g. with AH or ESP (IPsec) 
> > processing, what does this do to GIST?
> question is 
> > at the end (so please read all the way ...)
> > 
> answered by a 
> > the destination port for UDP MUST = GIST there MAY be arbitrary IP 
> > options the RAO MUST be included by the sender, but a node 
> MAY decide 
> > to intercept packets purely on protocol/port number analysis and so 
> In reading the current specs, the RAO in Q-Mode messages 
> seems mandatory, although it is not stated that explicitly. 
> Following that it seems logical that a node actually MUST NOT 
> decide to intercept packets purely on protocol/port number, 
> exactly for the reason of inadvertedly capturing non-GIST 
> traffic. Indeed, some parts of the GIST implementation I did 
> are built on the assumption that Q-Mode messages contain a RAO value.

that assumption is currently reasonable, and indeed can remain so. 
but it may be necessary to support alternative implementation
approaches.
see below.

> > routing/hop-by-hop options/destination options followed by UDP the 
> > destination port for UDP MUST = GIST the RAO MUST be 
> included by the 
> > sender, and it is RECOMMENDED that a node bases its initial 
> > interception decision purely on the presence of the RAO without 
> > analysing the header chain.
> > 
> > for either IP version:
> > 
> traffic (at a 
> > host). No other packets are GIST packets; this includes IP-in-IP 
> > tunnelled packets, other tunnelled packets (tunnel mode AH/ESP), or 
> > packets which have undergone some additional transport layer 
> > processing (transport mode AH/ESP). If IP output processing 
> at a node 
> > causes such additional encapsulations to be added to a GIST Q-mode 
> > encapsulation is terminated. If the node wishes to signal for data 
> > over the network region where the encapsulation applies, it MUST 
> > generate additional signalling with an MRI matching the 
> encapsulated 
> > traffic and outbound GIST Q-mode message MUST bypass the 
> encapsulation processing.
> > 
> > data. On packets forwarded by GIST (without NSLP processing), IP 
> > options MUST be processed as for a normally forwarded IP packet.
> > 
> > On packets locally delievered to the NSLP, the IP options MAY be 
> > passed to the NSLP and equivalent options used on subsequently 
> > generated outgoing Q-mode packets. In this case, routing related 
> > options on SHOULD be processed identically as for a 
> normally forwarded IP packet.
> > 
> > people want to suggest alternative text (or ask for clarifications) 
> > they are welcome to do so.
> 

thanks.

> 
> > The remaining question, following all this detail, is how to handle 
> > the possibility that GIST intercepts traffic which isn't 
> really GIST 
> > allocated through IANA. if they do, and their traffic gets 
> > intercepted, that is their bad luck.
> > 
> have to be 
> > some additional fact about the UDP payload which other 'random' 
> > traffic would not have. [Note: it's better not to rely on 
> the presence 
> > of the RAO for reasons noted above.] The most robust technique here 
> > would seem to be to require a magic 32-bit number at the 
> start of the 
> > UDP payload, and bypass packets which did not have it. This 
> is done in 
> > some other protocols (e.g. BGP, PPP). I just harvested 32 bits of 
> > What do people feel about this choice? At the moment, I 
> would prefer 
> > to do things the first way, but the second is not much 
> effort (just a 
> Continuing what I said above, if a Q-Mode message always 
> carries a RAO, there are actually two criteria to distinguish 
> GIST traffic from other traffic, i.e. the RAO option and the 
> destination UDP port. This to me seems sufficient.
> 
> So, this question only becomes relevant when you cannot rely 
> on the presence of the RAO. This however I feel would be a 
> change from the current specification. You indicate that 
> either removing the RAO field or making it optional would be 
> a separate discussion, but it is a discussion that should 
> precede this one. Until that time it's not much of a problem.

for the proposal, please see the separate email thread.

My personal take on this is that relying on the RAO as part of
the demultiplexing algorithm (except for performance speedups)
is conceptually dangerous. There are several aspects to this,
all depending on how you read rfc2113 (which is not the most
unambiguous document in the world); the key phrase in that spec
is the one giving the semantics of the RAO as 'routers should 
examine the packet more closely'. In that case:

- the RAO is meaningless at hosts. IP stacks would be at liberty
to strip it out on reception. (For our case, you could make an
exception for GIST traffic which would potentially require a 
GIST implementation to modify the IP stack, and there is also 
the case that for hosts, the OS should allow a GIST implementation
to detect/prevent other software using the same UDP port. So
maybe it is not such a big issue.)

- 'examine more closely' does not mean 'change the semantics
of the transport layer protocol and its payload'. In other words,
adding RAO to a packet does not make a packet into another sort
of packet - a GIST packet should "be" a GIST packet regardless of
the presence of the RAO or not. My conceptual algorithm for
Q-mode interception goes as follows (there are two cases):

case (a) [router handles RAO sensibly]
1) might this packet be a GIST packet?
	RAO included: yes; go to step 2
	RAO not included: no, forward normally
2) is this packet a GIST packet?
	proto = UDP & port = GIST: yes, do GIST processing
	proto != UDP or port != GIST: no, forward normally

case (b) [router ignores RAO]
1) might this packet be a GIST packet?
	yes
2) [same processing as for case (a)]

So, what we are really asking is whether the step 2 logic should
be changed (in this algorithm). Note that the RAO discussion
in the separate thread is basically saying that it might be 
necessary to send Q-mode packets without RAO in which case
there is an additional reason why case (b) might be being invoked.

cheers,

r.

---

From: Martin Stiemerling <[email-masked]>
Date: Thu, 15 Feb 2007 16:15:42 +0100

Hi Robert,

> This is part of the separate discussion on RAO handling in general.)

Ok. Should we say for "MAY decide to" the possible consequences,  
i.e., intercepting non-GIST traffic using UDP with the GIST port number?

> the destination port for UDP MUST = GIST

How about this slightly changed text:

the next-header field of the RAO extended header MUST either be UDP,
or some combination of IPv6 extension headers followed by UDP
and the destination port for UDP MUST = GIST

> the RAO without analysing the header chain.

(caution nit picker ahead :-)
"analysing the header chain" is probably too strong, as somebody could
read it "as do not even read" the header chain. A node must anyway  
analyse
the header chain for getting to the RAO. How about "without analysing  
the
single extension headers of the header chain"?

> forwarded

Fine with me!

> options

I fail to get the real meaning of the last sentence. I assume the  
difference is in the words "transmitted" in the first part and  
"forwarded" in the second part. Transmitted refers to "initiated by  
GIST" and "forwarded" as just reach through, i.e., touched by GIST  
but not handled on this node for whatever reason.

> passed

Fine with me.

> people want to suggest alternative text (or ask for clarifications)  

Almost all text is self-explanatory, expect the one sentence. This  
probably needs some rewording.

> the

This assumes that no RAO is present? Or nodes do not consider the RAO?
I see this less an end host issue but more a router issue. End host  
will either have GIST and discard/generate error when receiving non- 
GIST data, no issue here. Routers are more sensitive, as they would  
drop non-GIST data en-route.

> allocated through IANA. if they do, and their traffic gets  

Well, no good idea, at least not from an operational point of view.  
The middle of the network should not exclude certain ports to be used  
for other usage. "Be liberal in what you accept, and conservative in  
what you send" should be the rule.

> traffic

I like this idea better!

Thanks for summing it all up!

   Martin

> prefer to

[email-masked]
NEC Europe Limited |
Registered Office: NEC House, 1 Victoria Road, London W3 6BL |
Registered in England 2832014

---

From: "Hancock, Robert" <[email-masked]>
Date: Fri, 16 Feb 2007 15:08:26 -0000

hi, 

> From: Martin Stiemerling [mailto:[email-masked]] 
> Sent: 15 February 2007 15:16
> To: Hancock, Robert
> Cc: [email-masked]
> Ok. Should we say for "MAY decide to" the possible 
> consequences, i.e., intercepting non-GIST traffic using UDP 
> with the GIST port number?

that aspect will be in the final writeup for the spec, but I didn't 
want to get into it here.

> and the destination port for UDP MUST = GIST

NO NO NO NO NO NO (repeat ad nauseam)

the problem with IPv6 is that the term 'extension header' covers a whole
kitchen sink-full of additional protocols, most of which are *not* 
compatible with Q-mode (for example, AH, which is the cause of the 
original question, and ESP). of the next header field values allocated 
by IANA, i believe that only rtg/hbh/dest are meaningful here.

(note that there are some values apparently in the wild which are not
IANA-managed; for example, 135 for a mobility header defined by MIPv6.
unfortunately, the MIPv6 RFC refers to a non-existent appendix for
an explanation of what the mobility header is for, so it's hard to
judge whether it could meaningfully be used in Q-mode, but for now
I assume not.)

> single extension headers of the header chain"?

or even: 
it is RECOMMENDED that a node bases its initial interception decision 
purely on the presence of a hop-by-hop option header, which will be 
at the start of the header chain, containing the RAO.

> > be identified as GIST until the encapsulation is 
> terminated. If the  
> > node

OK: maybe 'transmitted' --> 'originated'. Is that clearer?

> > linux server (0x4e04 bda5) which would seem eminently suitable for  

cool.

any other views?

robert h.

---

From: Christian Dickmann <[email-masked]>
Date: Sun, 18 Feb 2007 20:36:23 -0500

Hi Robert,
> allocated through IANA. if they do, and their traffic gets intercepted,

This rule is fine for end hosts, but for routers it seems too strict. As 
UDP is an end-to-end protocol, I could assume that controlling both end 
points gives me all the right in the world to use any port number I 
want. I just have to assume that end-hosts not controlled by me might 
use that port for the "official" purpose. Thus, I would prefer the 
second solution, as it is no big deal to implement and specify, but 
greatly reduces the risk of a collision.

> change to the Q-mode encapsulation definition in section 5.3.2). 

Regards,
Christian Dickmann