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

From: Martin Stiemerling <[email-masked]>
Date: Wed, 7 Mar 2007 16:06:17 +0100

Hi,

Sorry for being late with my answer. Howerver, here we go!
>>>
>>> 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.)
>>
>> 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.

Ok, fine with me.

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

Ok, I see my fault here, i.e., you are right the term 'extension  
header' covers too much.

>
> (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.)
>
>>
>>
>>> 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.
>>
>> (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"?
>
> 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.

Ok, sounds good to me.

>
>>
>>>
>>> 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.
>>
>> Fine with me!
>>
>>>
>>> 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.
>>
>> 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.
>
> OK: maybe 'transmitted' --> 'originated'. Is that clearer?

Yes, much more clearer!

Thanks!!!

   Martin

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