Subject: Question about the need for a "Router Alert Option" (RFC 2711) within a Hop-By-Hop Option Extension Header (RFC 2460) ...

From: "John Spence" <[email-masked]>
Date: Tue, 1 Nov 2005 18:04:49 -0800

Hello;
 
If the H-B-H extension header means "all intermediate nodes must
look in here for options to process", why is the "Router Alert"
option needed?  As I read the text of the two RFCs, the Router
Alert Option is redundant - just including a H-B-H header means
"intermediate nodes must look at this packet even if it is not
addressed to them", which seems to be the same meaning as Router
Alert.
 
I must be missing something.  Can someone provide a quick answer,
or a pointer to the answer so I can research it myself?
 
Thanks very much.
 
John Spence

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Fred Baker <[email-masked]>
Date: Tue, 1 Nov 2005 18:48:05 -0800

one of them sounds like it is redundant. I think the Router Alert  
predated the HBH header...

> or a pointer to the answer so I can research it myself?

--------------------------------------------------------------
"Don't worry about the world coming to an end today. It's already  
tomorrow in Australia." (Charles Schulz )

---

From: vijay gill <[email-masked]>
Date: Tue, 01 Nov 2005 22:01:28 -0500

Fred Baker wrote:
>> If the H-B-H extension header means "all intermediate nodes must look 
>> in here for options to process", why is the "Router Alert" option 
>> needed?  As I read the text of the two RFCs, the Router Alert Option 
>> is redundant - just including a H-B-H header means "intermediate nodes 
>> must look at this packet even if it is not addressed to them", which 
>> seems to be the same meaning as Router Alert.

Sounds like nice DDoS attack vector on routers. I suspect this will soon 
be an option that can be turned off via configuration commands on the 
router.

/vijay

---

From: "John Spence" <[email-masked]>
Date: Tue, 1 Nov 2005 19:25:09 -0800

Thanks for the quick reply.  The Router Alert Option (RFC 2711)
is dated October 1999.  It says "This memo describes a new IPv6
Hop-by-Hop Option type ", so the Router Alert is designed for the
H-B-H Extension header.

----------------------------------------------------
John Spence, CCSI, CCNA, CISSP
Native6, Inc.
IPv6 Training and Consulting
[email-masked]
(wk) 206-682-0275
www.native6.com
----------------------------------------------------

  _____  

From: Fred Baker [mailto:[email-masked]] 
Sent: Tuesday, November 01, 2005 6:48 PM
To: John Spence
Cc: [email-masked]
Subject: Re: Question about the need for a "Router Alert Option"
(RFC 2711) within a Hop-By-Hop Option Extension Header (RFC 2460)
...

Hello;

Thanks very much.

John Spence

-----------------------------------------------------------------
---
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests:
https://www1.ietf.org/mailman/listinfo/ipv6
-----------------------------------------------------------------
---

---

From: Fred Baker <[email-masked]>
Date: Tue, 1 Nov 2005 21:12:06 -0800

more like something you turn on - by configuring the protocol that  
uses it.

On Nov 1, 2005, at 7:01 PM, vijay gill wrote:

> Sounds like nice DDoS attack vector on routers. I suspect this will  
> soon be an option that can be turned off via configuration commands  
> on the router.
>
> /vijay

---

From: Elwyn Davies <[email-masked]>
Date: Wed, 02 Nov 2005 08:04:25 +0000

The router alert option has a rather more drastic effect than simply 
having a h-b-h extension header.  The intention of the h-b-h header (as 
has been discussed recently in connection with a proposed QoS related 
option) is that h-b-h options should, by default, not need to be 
diverted to the 'slow path' and there should be generally no need to 
look at the rest of the packet. (see s2.0 of RFC2711 and the words about 
processing order in s4 of RFC2460).

The router alert option is intended to provide an override for this by 
forcing the router to look more deeply into the packet while putting 
minimal overhead into the h-b-h option processing.  The value in the 
option is intended to help decide what should happen at the earliest 
moment in processing in the router.

So, for example, an empty h-b-h header *should* not divert the packet 
from the fast path because there is no need to inspect the rest of the 
packet - this of course depends on the router implementation but that is 
the intention.  The only other example of a h-b-h option that is defined 
at the moment is the jumbo packet option which carries the packet length 
when it doesn't fit into 16 bits.  This fits the bill because the router 
needs to know how big the packet ought to be but doesn't need to look at 
the rest of the packet.. effectively it is just the packet length field 
in a different place.

The main users of the router alert option are path-coupled network layer 
signaling protocols which need to intercept signaling messages at 
on-path middleboxes.  RSVP is the current example and the nsis transport 
protocol also uses them.  There has been discussion in nsis about what 
router alert values should be used.   The view is that it would be good 
if routers were able to discriminate on the router alert value and only 
divert packets with 'interesting' (to that middlebox) values, ignoring 
other values. This would allow middleboxes to intercept just the 
signaling sub-protocols that are relevant to their function and bypass 
any others (e.g., a QoS gateway would generally not be interested in NAT 
signaling).  It would also minimize the effect of the DoS attack that 
has been discussed on this thread.

Hope this helps.

Regards,
Elwyn

John Spence wrote:

> I must be missing something.  Can someone provide a quick answer, or a 
> pointer to the answer so I can research it myself?
>  
> Thanks very much.
>  
> John Spence
>
>------------------------------------------------------------------------
>

---

From: "John Spence" <[email-masked]>
Date: Wed, 2 Nov 2005 14:29:30 -0800

Excellent. Thanks for the insight.

One comment - you did mention an "empty h-b-h header".  I would
not expect to see an empty one - right - only if I have options
would I attach the extension header to carry them.

Spence

>-----Original Message-----
>From: Elwyn Davies [mailto:[email-masked]] 
>Sent: Wednesday, November 02, 2005 12:04 AM
>To: John Spence
>Cc: [email-masked]
>Subject: Re: Question about the need for a "Router Alert 
>Option" (RFC 2711) within a Hop-By-Hop Option Extension Header 
>(RFC 2460) ...
>
>The router alert option has a rather more drastic effect than 
>simply having a h-b-h extension header.  The intention of the 
>h-b-h header (as has been discussed recently in connection 
>with a proposed QoS related
>option) is that h-b-h options should, by default, not need to 
>be diverted to the 'slow path' and there should be generally 
>no need to look at the rest of the packet. (see s2.0 of 
>RFC2711 and the words about processing order in s4 of RFC2460).
>
>The router alert option is intended to provide an override for 
>this by forcing the router to look more deeply into the packet 
>while putting minimal overhead into the h-b-h option 
>processing.  The value in the option is intended to help 
>decide what should happen at the earliest moment in processing 
>in the router.
>
>So, for example, an empty h-b-h header *should* not divert the 
>packet from the fast path because there is no need to inspect 
>the rest of the packet - this of course depends on the router 
>implementation but that is the intention.  The only other 
>example of a h-b-h option that is defined at the moment is the 
>jumbo packet option which carries the packet length when it 
>doesn't fit into 16 bits.  This fits the bill because the 
>router needs to know how big the packet ought to be but 
>doesn't need to look at the rest of the packet.. effectively 
>it is just the packet length field in a different place.
>
>The main users of the router alert option are path-coupled 
>network layer signaling protocols which need to intercept 
>signaling messages at on-path middleboxes.  RSVP is the 
>current example and the nsis transport protocol also uses 
>them.  There has been discussion in nsis about what 
>if routers were able to discriminate on the router alert value 
>and only divert packets with 'interesting' (to that middlebox) 
>values, ignoring other values. This would allow middleboxes to 
>intercept just the signaling sub-protocols that are relevant 
>to their function and bypass any others (e.g., a QoS gateway 
>would generally not be interested in NAT signaling).  It would 
>also minimize the effect of the DoS attack that has been 
>discussed on this thread.
>
>Hope this helps.
>
>Regards,
>Elwyn
>
>
>
>John Spence wrote:
>
>> Hello;
>>  
>---------
>>-