draft-ietf-intarea-router-alert-considerations-02.txt   draft-ietf-intarea-router-alert-considerations-03.txt 
Network Working Group F. Le Faucheur, Ed. Network Working Group F. Le Faucheur, Ed.
Internet-Draft Cisco Internet-Draft Cisco
Intended status: BCP October 25, 2010 Intended status: BCP March 10, 2011
Expires: April 28, 2011 Expires: September 11, 2011
IP Router Alert Considerations and Usage IP Router Alert Considerations and Usage
draft-ietf-intarea-router-alert-considerations-02 draft-ietf-intarea-router-alert-considerations-03
Abstract Abstract
The IP Router Alert Option is an IP option that alerts transit The IP Router Alert Option is an IP option that alerts transit
routers to more closely examine the contents of an IP packet. RSVP, routers to more closely examine the contents of an IP packet. RSVP,
PGM, IGMP/MLD, MRD and GIST are some of the protocols that make use PGM, IGMP/MLD, MRD and GIST are some of the protocols that make use
of the IP Router Alert option. This document discusses security of the IP Router Alert option. This document discusses security
aspects and usage guidelines around the use of the current IP Router aspects and usage guidelines around the use of the current IP Router
Alert option. Specifically, it provides recommendation against using Alert option. Specifically, it provides recommendation against using
the Router Alert in the end-to-end open Internet as well as identify the Router Alert in the end-to-end open Internet as well as identify
skipping to change at page 1, line 40 skipping to change at page 1, line 40
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 28, 2011. This Internet-Draft will expire on September 11, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 7, line 40 skipping to change at page 7, line 40
only allows very coarse triage among various protocols using IP only allows very coarse triage among various protocols using IP
Router Alert for two reasons. First, the next level protocol is the Router Alert for two reasons. First, the next level protocol is the
same when IP Router Alert is used for different applications of the same when IP Router Alert is used for different applications of the
same protocol (e.g., RSVP vs. RSVP-TE), or when IP Router Alert is same protocol (e.g., RSVP vs. RSVP-TE), or when IP Router Alert is
used for different contexts of the same application (e.g., different used for different contexts of the same application (e.g., different
levels of RSVP aggregation [RFC3175]). Thus, it is not possible to levels of RSVP aggregation [RFC3175]). Thus, it is not possible to
achieve the necessary triage in the fast path across IP Router Alert achieve the necessary triage in the fast path across IP Router Alert
packets from different applications or from different contexts of an packets from different applications or from different contexts of an
application. Secondly, some protocols requiring punting may be application. Secondly, some protocols requiring punting may be
carried over a transport protocol (e.g., TCP or UDP) possibly because carried over a transport protocol (e.g., TCP or UDP) possibly because
they require the services of that transport protocol or perhaps they require the services of that transport protocol, possibly
because the protocol does not justify allocation of a scarce next because the protocol does not justify allocation of a scarce next
level protocol value. Thus, considering the next level protocol does level protocol value or possibly because not relying on a very widely
not allow triage in the fast path of IP Router Alert packets from deployed transport protocol is likely to result in deployment issues
different protocols sharing the same transport protocol. Therefore, due to common middlebox behaviors (e.g. Firewalls or NATs discarding
it is generally not possible to ensure that only the IP Router Alert packets of "unkown" protocols). Thus, considering the next level
packets of interest are punted to the slow path while other IP Router protocol does not allow triage in the fast path of IP Router Alert
Alert packets are efficiently forwarded (i.e., in fast path). packets from different protocols sharing the same transport protocol.
Therefore, it is generally not possible to ensure that only the IP
Router Alert packets for next level protocols of interest are punted
to the slow path while other IP Router Alert packets are efficiently
forwarded (i.e., in fast path).
Some IP Router Alert implementations may be able to take into account Some IP Router Alert implementations may be able to take into account
the value field inside the router alert option. However, only one the value field inside the router alert option. However, only one
value (zero) was defined in [RFC2113] and no IANA registry for IPv4 value (zero) was defined in [RFC2113] and no IANA registry for IPv4
Router Alert values was available until recently. So this did not Router Alert values was available until recently ([RFC5350]). So
allow most IPv4 Router Alert implementation to support useful this did not allow most IPv4 Router Alert implementation to support
classification based on the value field in the fast path. Also, useful classification based on the value field in the fast path.
while [RFC2113] states that unknown values should be ignored (i.e. Also, while [RFC2113] states that unknown values should be ignored
The packets should be forwarded as normal IP traffic), it has been (i.e. The packets should be forwarded as normal IP traffic), it has
reported that some existing implementations simply ignore the value been reported that some existing implementations simply ignore the
field completely (i.e. Process any packet with an IPv4 Router Alert value field completely (i.e. Process any packet with an IPv4 Router
regardless of its option value). An IANA registry for further Alert regardless of its option value). An IANA registry for further
allocation of IPv4 Router Alert values has been introduced recently allocation of IPv4 Router Alert values has been introduced recently
([RFC5350]) but this would only allow coarse-grain classification, ([RFC5350]) but this would only allow coarse-grain classification,
when, and if, supported by implementations. For IPv6, [RFC2711] when, and if, supported by implementations. For IPv6, [RFC2711]
states that "the value field can be used by an implementation to states that "the value field can be used by an implementation to
speed processing of the datagram within the transit router" and speed processing of the datagram within the transit router" and
defines an IANA registry for these values. But again, this only defines an IANA registry for these values. But again, this only
allows coarse-grain classification. Besides, some existing IPv6 allows coarse-grain classification. Besides, some existing IPv6
Router Alert implementations are reported to depart from that Router Alert implementations are reported to depart from that
behavior. behavior.
skipping to change at page 22, line 8 skipping to change at page 22, line 8
* adrian@olddog.co.uk * adrian@olddog.co.uk
o Tony Li: o Tony Li:
* tony.li@tony.li * tony.li@tony.li
9. Acknowledgments 9. Acknowledgments
We would like to thank Dave Oran, Magnus Westerlund, John Scudder, We would like to thank Dave Oran, Magnus Westerlund, John Scudder,
Ron Bonica, Ross Callon, Alfred Hines and Carlos Pignataro for their Ron Bonica, Ross Callon, Alfred Hines, Carlos Pignataro and Roland
comments. This document also benefited from discussions with Jukka Bless for their comments. This document also benefited from
Manner and Suresh Krishnan. The discussion about use of the value discussions with Jukka Manner and Suresh Krishnan. The discussion
field in the IPv4 Router Alert borrowed from a similar discussion in about use of the value field in the IPv4 Router Alert borrowed from a
[I-D.ietf-nsis-ntlp]. similar discussion in [I-D.ietf-nsis-ntlp].
10. References 10. References
10.1. Normative References 10.1. Normative References
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981. September 1981.
[RFC1883] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC1883] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 1883, December 1995. (IPv6) Specification", RFC 1883, December 1995.
skipping to change at page 23, line 31 skipping to change at page 23, line 31
[RFC2711] Partridge, C. and A. Jackson, "IPv6 Router Alert Option", [RFC2711] Partridge, C. and A. Jackson, "IPv6 Router Alert Option",
RFC 2711, October 1999. RFC 2711, October 1999.
[RFC5350] Manner, J. and A. McDonald, "IANA Considerations for the [RFC5350] Manner, J. and A. McDonald, "IANA Considerations for the
IPv4 and IPv6 Router Alert Options", RFC 5350, IPv4 and IPv6 Router Alert Options", RFC 5350,
September 2008. September 2008.
10.2. Informative References 10.2. Informative References
[I-D.ietf-mpls-ip-options] [I-D.ietf-mpls-ip-options]
Jaeger, W., Mullooly, J., Scholl, T., and D. Smith, Jaeger, W., Mullooly, J., Scholl, T., and D. Smith, "Label
"Requirements for Label Edge Router Forwarding of IPv4 Edge Router Forwarding of IPv4 Option Packets",
Option Packets", draft-ietf-mpls-ip-options-04 (work in draft-ietf-mpls-ip-options-07 (work in progress),
progress), May 2010. December 2010.
[I-D.ietf-nsis-ntlp] [I-D.ietf-nsis-ntlp]
Schulzrinne, H. and M. Stiemerling, "GIST: General Schulzrinne, H. and M. Stiemerling, "GIST: General
Internet Signalling Transport", draft-ietf-nsis-ntlp-20 Internet Signalling Transport", draft-ietf-nsis-ntlp-20
(work in progress), June 2009. (work in progress), June 2009.
[I-D.krishnan-ipv6-hopbyhop] [I-D.krishnan-ipv6-hopbyhop]
Krishnan, S., "The case against Hop-by-Hop options", Krishnan, S., "The case against Hop-by-Hop options",
draft-krishnan-ipv6-hopbyhop-05 (work in progress), draft-krishnan-ipv6-hopbyhop-05 (work in progress),
October 2010. October 2010.
 End of changes. 9 change blocks. 
29 lines changed or deleted 33 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/