Re: New Routing Header!!!

["Vishwas Manral" <[e-mail]>]

Hi Velan,

I agree things are a bit confusing.

The idea however is very simple. A routing header is looked at only by
the node identified as the destination address in the IPv6 packet, so
the processing algorithm is to be done only on those nodes. A
firewall, any other middlebox, or even routers that do deep packet
processing (its done in a lot of ASIC's right now at line-rate) can
drop packets when they see discrepancies as identified in the draft
below.

The answer of how to process an unrecognized Routing Header is given
in page 12-13 of RFC2460. Do have a look and let me know if things are
clearer.

Thanks,
Vishwas

On 8/30/07, sengottuvelan srirangan <[e-mail]> wrote:
> Hi Viswas,
>
> I could not get the below comments in the draft:
>
> "
> A Routing header is not examined or processed until it reaches the node
> identified in the Destination Address field of the IPv6 header.
>
>  There can be at most one RH4 header in any packet. A packet with
>  more   than one RH4 header is discarded. This functionality can be
>  implemented  in a firewall or any other IPv6 node.
> :
> :
>  Whereever possible, including the administrative network edge, RPF
>  check needs to be done.
> "
>
> I have following comments on the draft:
>
> 1.  Draft recommends to implement the stack in  the destination nodes but
> also says , Whereever possible,including the administrative network edge,
> RPF check needs to be done. This functionality can be  implemented  in a
> firewall or any other IPv6 node.
> please clarify.
>
> 2. What if current IPv6 node receives RH4 header?. How do we handle the RH4
> header in the current implementaions?
>
>
> Regards
> Sengottuvelan
>
>
>
>
>
> Vishwas Manral <[e-mail]> wrote:
> Hi,
>
> Based on feedback from the group, we have written a draft for a new
> routing header. The functionality is the same as the RH0. The draft
> will soon be posted to the IETF site.
>
> The main differences are:
>
> 1. Maximum up to 4 addresses in the header. (the number is based on
> the reply I got for the question about the usage scenarios in operator
> environments).
> 2. Only one header in each packet.
> 3. Firewall policy reccomendation.
> 4. RPF reccomendation.
>
> Please have a look and let us know your comments.
>
> Thanks,
> Vishwas
>
>
> Network Working Group V. Manral
> Internet-Draft M. Dutta
> Updates: 2460, 4294 IP Infusion Inc.
> (if approved)
> Intended status: Standards Track
> Expires: February 28, 2008
> August 28, 2007
>
>
> New IPv6 Type 4 Routing Header
> draft-manral-ipv6-rh4-00
>
> Status of this Memo
>
> By submitting this Internet-Draft, each author represents that any
> applicable patent or other IPR claims of which he or she is aware
> have been or will be disclosed, and any of which he or she becomes
> aware will be disclosed, in accordance with Section 6 of BCP 79.
>
> Internet-Drafts are working documents of the Internet Engineering
> Task Force (IETF), its areas, and its working groups. Note that
> other groups may also distribute working documents as Internet-
> Drafts.
>
> Internet-Drafts are draft documents valid for a maximum of six months
> and may be updated, replaced, or obsoleted by other documents at any
> time. It is inappropriate to use Internet-Drafts as reference
> material or to cite them other than as "work in progress."
>
> The list of current Internet-Drafts can be accessed at
> http://www.ietf.org/ietf/1id-abstracts.txt.
>
> The list of Internet-Draft Shadow Directories can be accessed at
> http://www.ietf.org/shadow.html.
>
> This Internet-Draft will expire on December 28, 2007.
>
> Copyright Notice
>
> Copyright (C) The IETF Trust (2007).
>
> Abstract
>
> The functionality provided by IPv6's Type 0 Routing Header can be
> exploited in order to achieve traffic amplification over a remote
> path for the purposes of generating denial-of-service traffic.
>
> This document updates the IPv6 specification to the use of a new
> IPv6 Type 4 Routing Header, in light of this security concern. This
> new header provides the same functionality of the Routing Header
> Type-0, while taking care of the major security concerns defined
> in the draft [draft-ietf-ipv6-deprecate-rh0-01].
>
>
>
> Manral Expires February 28, 2008 [Page 1]
>
> Internet-Draft New IPv6 Type 4 Routing Header June 2007
>
>
> Table of Contents
>
> 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
> 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . 4
> 3. Format of RH4 . . . . . . . . . . . . . . . . . . . . . . . . 4
> 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
> 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
> 6. Acknowlegements . . . . . . . . . . . . . . . . . . . . . . . . 7
> 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
> 6.1. Normative References . . . . . . . . . . . . . . . . . . . 7
> 6.2. Informative References . . . . . . . . . . . . . . . . . . 8
> Appendix A. Change History . . . . . . . . . . . . . . . . . . . . 8
> Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
> Intellectual Property and Copyright Statements . . . . . . . . . . 10
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Manral Expires February 28, 2008 [Page 2]
>
> Internet-Draft New IPv6 Type 4 Routing Header June 2007
>
>
> 1. Introduction
>
> [RFC2460] defines an IPv6 extension header called "Routing Header",
> identified by a Next Header value of 43 in the immediately preceding
> header. A particular Routing Header subtype denoted as "Type 0" is
> also defined. Type 0 Routing Headers are referred to as "RH0" in
> this document.
>
> 128-fold amplification of data traffic can result using the IPv6
> amplification attack as defined in [I-D.ietf-ipv6-deprecate-rh0-01].
> This attack is particularly serious in that it affects the entire
> path between the two exploited nodes, not only the nodes themselves
> or their local networks.
>
> The draft [I-D.ietf-ipv6-deprecate-rh0-01] deprecates the use of the
> RH0 header. However operators use and require the functionality provided
> by the RH0 header.
>
> This draft defines the Routing Header of Type-4, and referred to as "RH4"
> header. The RH4 header has format and functionality similar to the RH0
> header without having the major vulnerabilities of the "Routing Header".
>
> This document updates [RFC2460] and [RFC4294].
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Manral Expires February 28, 2008 [Page 3]
>
> Internet-Draft New IPv6 Type 4 Routing Header June 2007
>
>
> 2. Definitions
>
> RH4 in this document denotes the IPv6 Extension Header type 43
> ("Routing Header") variant 4 ("Type 4 Routing Header"), is a type of
> Routing header as defined in [RFC2460].
>
> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
> document are to be interpreted as described in [RFC2119].
>
>
> 3. Format of RH4
>
> The Type 4 Routing header has the following format (it is the same as
> the RH0 header except for the limit on the "Hdr Ext Len" field. Some
> additional restrictions and checks have been added):
>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Next Header | Hdr Ext Len | Routing Type=0| Segments Left |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Reserved |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | |
> + +
> | |
> + Address[1] +
> | |
> + +
> | |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | |
> + +
> | |
> + Address[2] +
> | |
> + +
> | |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> . . .
> . . .
> . . .
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | |
> + +
> | |
> + Address[n] +
> | |
> + +
> | |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> Next Header 8-bit selector. Identifies the type of header
> immediately following the Routing header. Uses
> the same values as the IPv4 Protocol field
> [RFC-1700 et seq.].
>
> Hdr Ext Len 8-bit unsigned integer. Length of the Routing
> header in 8-octet units, not including the first
> 8 octets. For the Type 4 Routing header, Hdr
> Ext Len is equal to two times the number of
> addresses in the header. The maximum value of this
> field can be 8. That means a maximum of 4 addresses
> can be added to the Routing Header.
>
>
> Manral Expires February 28, 2008 [Page 4]
>
> Internet-Draft New IPv6 Type 4 Routing Header June 2007
>
>
>
> Routing Type 4.
>
> Segments Left 8-bit unsigned integer. Number of route
> segments remaining, i.e., number of explicitly
> listed intermediate nodes still to be visited
> before reaching the final destination.
>
> Reserved 32-bit reserved field. Initialized to zero for
> transmission; ignored on reception.
>
> Address[1..n] Vector of 128-bit addresses, numbered 1 to n. The
> maximum value of n is 4.
>
> Multicast addresses or Link Local Unicast address must not appear in a
> Routing header of Type 4, or in the IPv6 Destination Address field of
> a packet carrying a Routing header of Type 4.
>
> A Routing header is not examined or processed until it reaches the
> node identified in the Destination Address field of the IPv6 header.
> There can be at most one RH4 header in any packet. A packet with more
> than one RH4 header is discarded. This functionality can be implemented
> in a firewall or any other IPv6 node.
>
> In that node, dispatching on the Next Header field of the immediately
> preceding header causes the Routing header module to be invoked,
> which, in the case of Routing Type 4, performs the algorithm which is
> similar to the as specified in section 4.4 of [RFC2460]:
>
>
>
>
>
>
>
>
>
>
>
> Manral Expires February 28, 2008 [Page 5]
>
> Internet-Draft New IPv6 Type 4 Routing Header June 2007
>
>
> if Segments Left = 0 {
> proceed to process the next header in the packet, whose type is
> identified by the Next Header field in the Routing header
> }
> else if Hdr Ext Len is odd {
> send an ICMP Parameter Problem, Code 0, message to the Source
> Address, pointing to the Hdr Ext Len field, and discard the
> packet
> }
> else {
> compute n, the number of addresses in the Routing header, by
> dividing Hdr Ext Len by 2
>
> if Segments Left is greater than n or n is greater than 4 {
> send an ICMP Parameter Problem, Code 0, message to the Source
> Address, pointing to the Segments Left field, and discard the
> packet
> }
> else {
> decrement Segments Left by 1;
> compute i, the index of the next address to be visited in
> the address vector, by subtracting Segments Left from n
>
> if Address [i] or the IPv6 Destination Address is multicast
> or link local unicast address {
> discard the packet
> }
> else {
> Compare the addresses in the Routing Header to check that
> none of the address belong to the routers self address
>
> if overlapping address exist {
> discard the packet
> }
>
> swap the IPv6 Destination Address and Address[i]
>
> if the IPv6 Hop Limit is less than or equal to 1 {
> send an ICMP Time Exceeded -- Hop Limit Exceeded in
> Transit message to the Source Address and discard the
> packet
> }
> else {
> decrement the Hop Limit by 1
>
> resubmit the packet to the IPv6 module for transmission
> to the new destination
> }
> }
> }
> }
>
>
>
>
>
> Manral Expires February 28, 2008 [Page 6]
>
> Internet-Draft New IPv6 Type 4 Routing Header June 2007
>
>
> 4. Security Considerations
>
> The purpose of this document is to add a new type of Routing extension
> header of IPv6. RH0 has been shown to have undesirable security
> implications.
>
> Many of the attacks including the amplification attack cannot occur with
> the RH4 header. All the addresses in the RH4 header need to be checked with
> the firewall policy to make sure the firewall is able to trap packets meant
> for addresses in the firewall policy and take relevent action.
>
> Whereever possible, including the administrative network edge, RPF check
> needs to be done.
>
>
> 5. IANA Considerations
>
> The IANA registry "Internet Protocol Version 6 (IPv6) Parameters"
> should be updated to reflect that variant 4 of IPv6 header-type 43
> ("Routing Header") is added.
>
>
> 7. Acknowlegements
>
> This document benefits from the contributions of many IPV6 and V6OPS
> working group participants, including Chris Morrow, Tony Hain, Jinmei
> Tatuya and Brian Carpenter.
>
>
> 8. References
>
> 8.1. Normative References
>
> [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
> Requirement Levels", BCP 14, RFC 2119, March 1997.
>
>
>
> Manral Expires February 28, 2008 [Page 7]
>
> Internet-Draft New IPv6 Type 4 Routing Header June 2007
>
>
> [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
> (IPv6) Specification", RFC 2460, December 1998.
>
> [RFC4294] Loughney, J., "IPv6 Node Requirements", RFC 4294,
> April 2006.
>
> 8.2. Informative References
>
> [CanSecWest07]
> BIONDI, P. and A. EBALARD, "IPv6 Routing Header Security",
> CanSecWest Security Conference 2007, April 2007.
>
> http://www.secdev.org/conf/IPv6_RH_security-csw07.pdf
>
> [I-D.ietf-v6ops-security-overview]
> Davies, E., "IPv6 Transition/Co-existence Security
> Considerations", draft-ietf-v6ops-security-overview-06
> (work in progress), October 2006.
>
> [I-D.savola-ipv6-rh-ha-security]
> Savola, P., "Security of IPv6 Routing Header and Home
> Address Options", draft-savola-ipv6-rh-ha-security-02
> (work in progress), March 2002.
>
> [I-D.savola-ipv6-rh-hosts]
> Savola, P., "Note about Routing Header Processing on IPv6
> Hosts", draft-savola-ipv6-rh-hosts-00 (work in progress),
> February 2002.
>
> [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
> Defeating Denial of Service Attacks which employ IP Source
> Address Spoofing", BCP 38, RFC 2827, May 2000.
>
> [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
> Networks", BCP 84, RFC 3704, March 2004.
>
> [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
> in IPv6", RFC 3775, June 2004.
>
>
> Appendix A. Change History
>
> This section to be removed prior to publication.
>
>
>
>
>
>
> Manral Expires February 28, 2008 [Page 8]
>
> Internet-Draft New IPv6 Type 4 Routing Header June 2007
>
>
> Authors' Addresses
>
> Vishwas Manral
> IP Infusion Inc,
> Bamankhola
> Bansgali
> Almora - Uttaranchal
> Phone: [phone]
> Email: [e-mail]
>
>
> Manoj Dutta
> IP Infusion Inc,
> 125, S. Market Street,
> San Jose, CA
> Phone: [phone]
> Email: [e-mail]
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Manral Expires February 28, 2008 [Page 9]
>
> Internet-Draft New IPv6 Type 4 Routing Header June 2007
>
>
> Full Copyright Statement
>
> Copyright (C) The IETF Trust (2007).
>
> This document is subject to the rights, licenses and restrictions
> contained in BCP 78, and except as set forth therein, the authors
> retain all their rights.
>
> This document and the information contained herein are provided on an
> "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
> OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
> THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
> OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
> THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
> WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
>
>
> Intellectual Property
>
> The IETF takes no position regarding the validity or scope of any
> Intellectual Property Rights or other rights that might be claimed to
> pertain to the implementation or use of the technology described in
> this document or the extent to which any license under such rights
> might or might not be available; nor does it represent that it has
> made any independent effort to identify any such rights. Information
> on the procedures with respect to rights in RFC documents can be
> found in BCP 78 and BCP 79.
>
> Copies of IPR disclosures made to the IETF Secretariat and any
> assurances of licenses to be made available, or the result of an
> attempt made to obtain a general license or permission for the use of
> such proprietary rights by implementers or users of this
> specification can be obtained from the IETF on-line IPR repository at
> http://www.ietf.org/ipr.
>
> The IETF invites any interested party to bring to its attention any
> copyrights, patents or patent applications, or other proprietary
> rights that may cover technology that may be required to implement
> this standard. Please address the information to the IETF at
> [e-mail].
>
>
> Acknowledgment
>
> Funding for the RFC Editor function is provided by the IETF
> Administrative Support Activity (IASA).
>
>
>
>
>
> Manral Expires February 28, 2008 [Page 10]
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests:
> https://www1.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>
>
>
>  ________________________________
> Pinpoint customers who are looking for what you sell.
>
>

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