Subject: Re: [Mip6] Deprecating Routing Header Type 0

From: Tim Enos <[email-masked]>
Date: Tue, 26 Jun 2007 14:22:30 -0500 (CDT)

Hello all,

This is a good discussion to have.

As there was much overlap between the first two listed drafts:
 
http://ietf.org/internet-drafts/draft-savola-ipv6-rtheader-00.txt

http://ietf.org/internet-drafts/draft-jabley-ipv6-rh0-is-evil-00.txt

A combined effort was begun, the most recently published version thereof being the following:

http://www.ietf.org/internet-drafts/draft-ietf-ipv6-deprecate-rh0-00.txt

AFAIK, in no case in any of the above linked documents (or elsewhere for that matter) do any of the draft authors advocate/suggest blocking all packets containing any routing header.

Even though the draft is merely focusing on RH0 deprecation (and not firewall policy per se), the text of section 4.2 below should be clear.

Quoting directly from -ietf-ipv6-deprecate-rh0-00:

"4.2.  Packet Filtering

Firewall policy intended to protect against packets containing RH0 should be constructed such that routing headers of other types (which may well have legitimate and benign applications) are handled on their own merits.  For example, discarding all packets with any type of routing header simply as a reaction to the problems with RH0 is inappropriate, and may hamper future functionality designed using non-type 0 routing headers.  For example, Mobile IPv6 uses the type 2
Routing Header [RFC3775].

Where filtering capabilities do not facilitate matching specific types of Routing Headers, filtering based on the presence of any Routing Headers on IPv6 routers, regardless of type, is strongly discouraged."

It can be seen that the above imprecation remains in the current draft revision candidate (as clearly pointed out by Jean-Michel).

Hope this helps,

Best Regards,

Tim Enos
Rom 8:28

>Hi,
>
>it seems that the issue is solved (from the new pre-version of the draft):
>"Firewall policy intended to protect against packets containing RH0
>MUST NOT simply filter all traffic with a routing header; it must be
>possible to disable forwarding of type 0 traffic without blocking
>other types of routing headers. In addition, the default configuration
>MUST permit forwarding of traffic using a RH other than 0."
>Source: http://www1.ietf.org/mail-archive/web/ipv6/current/msg07849.html
>
>Best regards.
>
>JMC.
>
>2007/6/17, Vijay Devarapalli <[email-masked]>:
>> Hello folks,
>>
>> There is a discussion going on in the IPv6 WG about deprecating
>> the use of Routing Header Type 0. See the following URL for the
>> discussion on this topic.
>>
>> http://www1.ietf.org/mail-archive/web/ipv6/current/msg07634.html
>>
>> For more information on security threats due to Routing Header
>> Type 0, see http://www.secdev.org/conf/IPv6_RH_security-csw07.pdf.
>> It is an interesting read.
>>
>> Some folks are suggesting "knee-jerk" reactions of blocking all
>> messages with a routing header in them. This would of course
>> break MIPv6. MIPv6 uses Router Header Type 2. It would be
>> especially bad if the firewalls start blocking them instead of
>> the hosts or the routers that receive such messages.
>>
>> Comments?
>>
>> Vijay
>>
>>
>> _______________________________________________
>> Mip6 mailing list
>> [email-masked]
>> https://www1.ietf.org/mailman/listinfo/mip6
>>
>
>_______________________________________________
>Mip6 mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/mip6

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

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 26 Jun 2007 12:28:41 -0700

> AFAIK, in no case in any of the above linked documents (or elsewhere for that matter) do any of the draft authors advocate/suggest blocking all packets containing any routing header.

True. But there were other emails on the IPv6 mailing list which
said block all, then enable for each application. I would like
"block RH0, allow all other", at least as far as IETF specification
goes. In practice, it could be different and not in our control.

Regarding the draft, I was looking for much stronger language about
firewalls not blocking all messages with a routing header. The new
version has this stronger language.

Vijay