Subject: [NSIS] outline changes to RAO handling in GIST

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

Hi,

At the last IETF (and in fact, before it also) there were some
intensive discussions on the way that GIST uses the RAO in
Q-mode packets. The details are in the proceedings 
(http://www3.ietf.org/proceedings/06nov/slides/nsis-1/sld1.htm and
http://www3.ietf.org/proceedings/06nov/minutes/nsis.txt).

The upshot of all these discussions is that there will be some
changes to the way the GIST draft describes the RAO usage. A
certain amount of that will be editorial clarifications;
however, there are some aspects which would not be purely
editorial.

The specific points that came up (some have come up before) are:
*) some routers may block packets with IPv4 options. We see this
already in cross-network experiments.
*) some routers are not able to intercept based on option value
(this seems to be mainly a point about future silicon developments),
but may still be able to do tuple-based classification.
*) some routers may handle the case of a IPv4/UDP packet with RAO 
(even if the RAO value != 0) in such a way that it is either 
dropped or rejected (this is the case that we have not been 
able to discover experimentally, but is asserted to exist; 
it is not clear whether this behaviour is consistent with the 
RAO spec but to some extent that is a moot point if implementations 
already do it).

The proposal is therefore to allow (MAY) GIST to send Q-mode packets
without the RAO and for GIST nodes to intercept these packets and
subject them to normal Q-mode processing; but since the intention
is to use this only to handle specific deployment cases and legacy
implementations, that this MUST be disabled by default and MUST only
be enabled selectively for specific destination subnets.

hopefully this clarifies some of the background to the 'What is GIST
traffic?' question. If there are comments on the above, that would
also be welcome.

robert h.

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

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Thu, 15 Feb 2007 15:17:30 +0100

Hi Robert 

Regading the following paragraph, I do not understand the following:
> The proposal is therefore to allow (MAY) GIST to send Q-mode 
> packets without the RAO and for GIST nodes to intercept these 
> packets and subject them to normal Q-mode processing; but 
> since the intention is to use this only to handle specific 
> deployment cases and legacy implementations, that this MUST 
> be disabled by default and MUST only be enabled selectively 
> for specific destination subnets.

What MUST be disabled? I do not understand?

Are you saying that GIST MUST allways send Q-mode packets 
with the RAO set and for GIST nodes to intercept only these 
packets (with RAO) and subject them to normal Q-mode processing;

Best regards,
Georgios

> -----Original Message-----
> From: Hancock, Robert [mailto:[email-masked]] 
> Sent: donderdag 15 februari 2007 13:42
> To: [email-masked]
> Subject: [NSIS] outline changes to RAO handling in GIST
> 
> Hi,
> 
> At the last IETF (and in fact, before it also) there were 
> some intensive discussions on the way that GIST uses the RAO 
> in Q-mode packets. The details are in the proceedings 
> (http://www3.ietf.org/proceedings/06nov/slides/nsis-1/sld1.htm
>  and http://www3.ietf.org/proceedings/06nov/minutes/nsis.txt).
> 
> The upshot of all these discussions is that there will be 
> some changes to the way the GIST draft describes the RAO 
> usage. A certain amount of that will be editorial 
> clarifications; however, there are some aspects which would 
> not be purely editorial.
> 
> *) some routers may block packets with IPv4 options. We see 
> this already in cross-network experiments.
> *) some routers are not able to intercept based on option 
> value (this seems to be mainly a point about future silicon 
> developments), but may still be able to do tuple-based classification.
> *) some routers may handle the case of a IPv4/UDP packet with 
> RAO (even if the RAO value != 0) in such a way that it is 
> either dropped or rejected (this is the case that we have not 
> been able to discover experimentally, but is asserted to 
> exist; it is not clear whether this behaviour is consistent 
> with the RAO spec but to some extent that is a moot point if 
> implementations already do it).
> 
> The proposal is therefore to allow (MAY) GIST to send Q-mode 
> packets without the RAO and for GIST nodes to intercept these 
> packets and subject them to normal Q-mode processing; but 
> since the intention is to use this only to handle specific 
> deployment cases and legacy implementations, that this MUST 
> be disabled by default and MUST only be enabled selectively 
> for specific destination subnets.
> 
> hopefully this clarifies some of the background to the 'What 
> is GIST traffic?' question. If there are comments on the 
> above, that would also be welcome.
> 
> robert h.
> 
> 
> 
>

---

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

hi, 

> From: Georgios Karagiannis [mailto:[email-masked]] 
> Sent: 15 February 2007 14:18
> To: Hancock, Robert; [email-masked]
> Subject: RE: [NSIS] outline changes to RAO handling in GIST
> 
> Hi Robert 
> 
> > subject them to normal Q-mode processing; but since the 
> intention is 
> > to use this only to handle specific deployment cases and legacy 

no; that is what the current spec says! (it would not be a change).

how about another go:

The default is that you MUST include the RAO on Q-mode packets.

implementations MAY allow an option to configure that an RAO is not
included in Q-mode packets; however, this option MUST NOT be enabled 
as a default, and MUST only be enabled for specific destinations.
[Presumably, destinations where there has been out-of-band 
verification that a GIST node along the path to that destination
can intercept such packets.]

clearer?

robert h.

> > intensive discussions on the way that GIST uses the RAO in Q-mode 
> > packets. The details are in the proceedings 
> some changes 
> > to the way the GIST draft describes the RAO usage. A 
> certain amount of 
> > that will be editorial clarifications; however, there are 
> some aspects 
> > which would not be purely editorial.
> > 
> value (this 
> > seems to be mainly a point about future silicon 
> developments), but may 
> > still be able to do tuple-based classification.
> > (even if the RAO value != 0) in such a way that it is 
> either dropped 
> > or rejected (this is the case that we have not been able to 
> discover 
> > experimentally, but is asserted to exist; it is not clear 
> whether this 
> > behaviour is consistent with the RAO spec but to some 
> extent that is a 
> > moot point if implementations already do it).
> > 
> > subject them to normal Q-mode processing; but since the 
> intention is 
> > to use this only to handle specific deployment cases and legacy

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Thu, 15 Feb 2007 15:39:54 +0100

Hi Robert

Thanks, now it is clear!
I will have to study your proposal very carefully and 
comment on it later!

Best regards,
Georgios

> Sent: donderdag 15 februari 2007 15:28
> To: Georgios Karagiannis; [email-masked]
> with the RAO 
> > set and for GIST nodes to intercept only these packets 
> (with RAO) and 
> > subject them to normal Q-mode processing;
> 
> implementations MAY allow an option to configure that an RAO 
> is not included in Q-mode packets; however, this option MUST 
> NOT be enabled as a default, and MUST only be enabled for 
> specific destinations.
> verification that a GIST node along the path to that 
> destination can intercept such packets.]
> 
> clearer?
> 
> robert h.
> 
> > 
> > Best regards,
> > Georgios
> > 
> >

---

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

> able to discover experimentally, but is asserted to exist;

FreeBSD has this issue: It accepts any packet with RAO and delivers  
it to the upper layer (here UDP). The FreeBSD box is generating an  
ICMP error message, because there is no one listening locally on the  
respective UDP port. Not completely the same as described but with  
the same result.

> RAO spec but to some extent that is a moot point if implementations

I do not see this behaviour consistent with the RAO spec.

> be enabled selectively for specific destination subnets.

That is OK, as long as we describe the caveats (in both directions  
pro and cons) of just using "without RAO".
As said in the email before on GIST D-MODE, we will need some magic  
cookie in the UDP to distinguish GIST UDP traffic from other UDP  
traffic on the same port.

Thanks,

   Martin

> traffic?' question. If there are comments on the above, that would

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

---

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

Am 15.02.2007 um 15:27 schrieb Hancock, Robert:

[...]

> []

Some wording question:
Can we tell what implementations are really doing? Otherwise the text  
sounds good!

   Martin

---

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

hi, 

> From: Martin Stiemerling [mailto:[email-masked]] 
> Sent: 15 February 2007 15:37
> To: Hancock, Robert
> Cc: Georgios Karagiannis; [email-masked]
> Subject: Re: [NSIS] outline changes to RAO handling in GIST
> 
> 
> >> Are you saying that GIST MUST allways send Q-mode packets with the 
> >> RAO set and for GIST nodes to intercept only these packets 
> (with RAO) 
> >> and subject them to normal Q-mode processing;
> >
> Can we tell what implementations are really doing? Otherwise 
> the text sounds good!

i don't see a problem; the concept of an implementation configuration
switch (especially to handle transition issues of this sort) is not
unknown
(e.g. rfc1812 sec5.3.8, 2812 sec4.6, 3810 sec10.2, 3971 sec8, ...)

r.

> Registered Office: NEC House, 1 Victoria Road, London W3 6BL 
> | Registered in England 2832014
> 
> 
> 
>

---

From: Andrew McDonald <[email-masked]>
Date: Thu, 15 Feb 2007 18:07:38 +0000

Martin Stiemerling wrote:
> FreeBSD has this issue: It accepts any packet with RAO and delivers it 
> to the upper layer (here UDP). The FreeBSD box is generating an ICMP 
> error message, because there is no one listening locally on the 
> respective UDP port. Not completely the same as described but with the 
> same result.
> 

 From when I looked at this in FreeBSD 7 (HEAD) before IETF67, I believe 
this is true for the IPv6 implementation, but not IPv4. As far as I 
could tell FreeBSD has no handling for IPv4 router alert options, but 
does have special processing for IP proto RSVP.

Andrew

---

From: Martin Stiemerling <[email-masked]>
Date: Thu, 15 Feb 2007 21:18:03 +0100

> (e.g. rfc1812 sec5.3.8, 2812 sec4.6, 3810 sec10.2, 3971 sec8, ...)

Ok, fine with me.

Thanks

   Martin

---

From: Martin Stiemerling <[email-masked]>
Date: Thu, 15 Feb 2007 21:27:29 +0100

Am 15.02.2007 um 19:07 schrieb Andrew McDonald:

>> FreeBSD has this issue: It accepts any packet with RAO and  
>> delivers it to the upper layer (here UDP). The FreeBSD box is  
>> generating an ICMP error message, because there is no one  
>> listening locally on the respective UDP port. Not completely the  
>> same as described but with the same result.
> From when I looked at this in FreeBSD 7 (HEAD) before IETF67, I  
> believe this is true for the IPv6 implementation, but not IPv4. As  
> far as I could tell FreeBSD has no handling for IPv4 router alert  
> options, but does have special processing for IP proto RSVP.

After checking again I can confirm that. The trouble line is in  
ip6_input.c since a long time:
                 if (rtalert != ~0 && ip6_forwarding)
                         ours = 1;

   Martin

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Fri, 16 Feb 2007 10:26:55 +0100

Hi Robert 

The problem that I have with the following sentence:
> implementations MAY allow an option to configure that an 
> RAO is not included in Q-mode packets; however, this option MUST NOT
> be enabled as a default, and MUST only be enabled for specific
destinations. 

What if a RAO is not included in a message and a domain must apply the
bypassing (due to aggregation)
feature. How will this feature then be supported?

Best Regards,
Georgios

> Sent: donderdag 15 februari 2007 17:06
> To: Martin Stiemerling
> i don't see a problem; the concept of an implementation 
> configuration switch (especially to handle transition issues 
> of this sort) is not unknown (e.g. rfc1812 sec5.3.8, 2812 
> sec4.6, 3810 sec10.2, 3971 sec8, ...)
> 
> r.
> 
> > 
> >    Martin
> > 
> >

---

From: "Hancock, Robert" <[email-masked]>
Date: Fri, 16 Feb 2007 09:49:54 -0000

hi, 

> Sent: 16 February 2007 09:27
> To: Hancock, Robert; 'Martin Stiemerling'
> Cc: [email-masked]

> What if a RAO is not included in a message and a domain must 
> apply the bypassing (due to aggregation) feature. How will 
> this feature then be supported?

it depends:

- if signalling enters the domain with no RAO, and the domain borders
depends on RAO, then the signalling will transit the domain 
transparently (it just looks like normal traffic). whoever initiated
the signalling won't get QoS (or whatever) services from the domain,
but the domain is unaffected.

- but in this case, one has to ask why the originator would have 
switched on the RAO in the first place. presumably it's because
signalling packets are being dropped or rejected somewhere. however,
that clearly isn't happening in the domain you are talking about
(since that supports NSIS properly). so the right place to drop
the RAO would be at the domain egress.

does this help?

r.

> > RAO is not
> configuration 
> > unknown (e.g. rfc1812 sec5.3.8, 2812 sec4.6, 3810 sec10.2, 
> 3971 sec8, 
> > ...)
> > 
> > r.
> > 
> > > 
> > >    Martin
> > > 
> > >

---

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

Hi Robert,

> subject them to normal Q-mode processing; 

OK, so you say Querying nodes MAY send Q-mode packets without RAO (but 
default MUST be to enable RAO).
But what about the intercepting part? Is it MAY too or SHOULD? Whats 
your suggestion?
Because sending a non-RAO Q-mode packet without anyone interpreting it 
is of no big use, is it?

Another question regarding the "MUST" for the default configuration:
Would it be OK to ship a list of known networks that do not support RAO 
with the implementation and set the default for those networks to "no RAO"?
What if the sender himself is using an ISP that drops (or otherwise 
corrupts) Q-mode packets with RAO? Then _all_ destinations should be set 
to "no RAO". I am not sure if you allow this when you say "and MUST only 
be enabled selectively for specific destination subnets".

BTW: I can confirm that a well-known large ISP in Germany does not 
support RAO packets (they are redirected and finally dropped).

Christian Dickmann

---

From: "Robert Hancock" <[email-masked]>
Date: Tue, 20 Feb 2007 09:33:51 -0000

hi, 

> From: Christian Dickmann [mailto:[email-masked]] 
> Sent: 19 February 2007 01:18
> To: Hancock, Robert
> Cc: [email-masked]
> OK, so you say Querying nodes MAY send Q-mode packets without 
> RAO (but default MUST be to enable RAO).
> But what about the intercepting part? Is it MAY too or 
> SHOULD? 

This would also be a MAY:
- I don't think it's reasonable to demand that nodes do this
  (else we might as well not bother with the RAO at all)
- However, for some implementations it might actually be easier
  to do UDP/port-based interception than RAO-based interception

The key point is that the sender must not (or MUST NOT) assume
that the downstream node is capable of intercepting such packets,
it must establish that it is beforehand. (Or, conversely, that 
there is no downstream node that can receive RAO'd packets for 
whatever reason).

> Whats your suggestion?
> Because sending a non-RAO Q-mode packet without anyone 
> interpreting it is of no big use, is it?

Exactly. This is supposed to be something that is done
between explicitly consenting implementations.

> Would it be OK to ship a list of known networks that do not 
> support RAO with the implementation and set the default for 
> those networks to "no RAO"?

I think not, or at least it's dangerous: after all, you would have
to maintain the list as part of the implementation, which would be
unpleasant. OTOH providing a readme saying "as of dd/mm/yy these
are the misbehaving networks and this is how we discovered them
and this is how to configure this implementation not to use RAO
for them" would seem reasonable.

> corrupts) Q-mode packets with RAO? Then _all_ destinations 
> should be set to "no RAO". I am not sure if you allow this 
> when you say "and MUST only be enabled selectively for 
> specific destination subnets".

0.0.0.0/0 is a destination subnet ;-)

> BTW: I can confirm that a well-known large ISP in Germany 
> does not support RAO packets (they are redirected and finally 
> dropped).

shame on them...

robert h.