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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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: +91 98456 61911 > Email: [EMAIL PROTECTED] > > > Manoj Dutta > IP Infusion Inc, > 125, S. Market Street, > San Jose, CA > Phone: 408 794 1500 > Email: [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 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 > [EMAIL PROTECTED] > > > 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 > ipv6@ietf.org > Administrative Requests: > https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > > > > ________________________________ > Pinpoint customers who are looking for what you sell. > > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------