One document matched: draft-baker-ipv6-nd-session-hijack-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- Some of the more generally applicable PIs that most I-Ds might want to use -->
<!-- Try to enforce the ID-nits conventions and DTD validity -->
<?rfc strict="yes" ?>
<!-- Items used when reviewing the document -->
<?rfc comments="no" ?>
<!-- Controls display of <cref> elements -->
<?rfc inline="no" ?>
<!-- When no, put comments at end in comments section,
otherwise, put inline -->
<?rfc editing="no" ?>
<!-- When yes, insert editing marks: editing marks consist of a
string such as <29> printed in the blank line at the
beginning of each paragraph of text. -->
<!-- Create Table of Contents (ToC) and set some options for it.
Note the ToC may be omitted for very short documents,but idnits insists on a ToC
if the document has more than 15 pages. -->
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<!-- If "yes" eliminates blank lines before main section entries. -->
<?rfc tocdepth="3"?>
<!-- Sets the number of levels of sections/subsections... in ToC -->
<!-- Choose the options for the references.
Some like symbolic tags in the references (and citations) and others prefer
numbers. The RFC Editor always uses symbolic tags.
The tags used are the anchor attributes of the references. -->
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<!-- If "yes", causes the references to be sorted in order of tags.
This doesn't have any effect unless symrefs is "yes" also. -->
<!-- These two save paper: Just setting compact to "yes" makes savings by not starting each
main section on a new page but does not omit the blank lines between list items.
If subcompact is also "yes" the blank lines between list items are also omitted. -->
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<!-- end of list of popular I-D processing instructions -->
<!-- end of list of processing instructions -->
<rfc category="info" docName="draft-baker-ipv6-nd-session-hijack-00"
ipr="trust200902">
<front>
<title abbrev="">Session Hijack in Neighbor Discovery</title>
<author fullname="Fred Baker" initials="F.J." surname="Baker">
<organization>Cisco Systems</organization>
<address>
<postal>
<street></street>
<city>Santa Barbara</city>
<code>93117</code>
<region>California</region>
<country>USA</country>
</postal>
<email>fred@cisco.com</email>
</address>
</author>
<date year="2009" />
<area>Internet</area>
<workgroup>IPv6 Maintenance</workgroup>
<abstract>
<t>This memo is to point out a security issue in IPv6 Neighbor
Discovery.</t>
</abstract>
<!--
<note title="Foreword">
</note>
-->
<!--
<note title="Requirements">
<t>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 <xref
target="RFC2119"></xref>.</t>
</note>
-->
<!--
<?rfc needLines="10" ?>
<texttable anchor="table_example" title="A Very Simple Table">
<preamble>Tables use ttcol to define column headers and widths.
Every cell then has a "c" element for its content.</preamble>
<ttcol align="center">ttcol #1</ttcol>
<ttcol align="center">ttcol #2</ttcol>
<c>c #1</c> <c>c #2</c>
<c>c #3</c> <c>c #4</c>
<c>c #5</c> <c>c #6</c>
<postamble>which is a very simple example.</postamble>
</texttable>
-->
</front>
<middle>
<!--
<t>There are multiple list styles: "symbols", "letters", "numbers",
"hanging", "format", etc.</t>
<t>
<list style="symbols">
<t>First bullet</t>
<t>Second bullet</t>
</list>
</t>
-->
<!--
<figure anchor="reference" title="Figure">
<artwork align="center">
<![CDATA[
ASCII artwork goes here...
]]>
</artwork>
</figure>
-->
<section title="Introduction">
<t>This memo, which augments <xref target="RFC3756"></xref>, is to point
out a security issue in <xref target="RFC2460">IPv6</xref>, <xref
target="RFC4861">Neighbor Discovery</xref> and <xref
target="RFC3971">Secure Neighbor Discovery</xref>.</t>
</section>
<section anchor="hijack" title="Session Hijack via Neighbor Discovery">
<t>The attack is as follows. Imagine a LAN (wired or wireless, switched
or direct) like <xref target="figure1"></xref> or <xref
target="figure2"></xref>.</t>
<figure anchor="figure1" title="Sample local session">
<artwork align="center"><![CDATA[
/---+--------+-------+---/
| | |
+---+--+ +---+--+ +--+---+
|Host 1| |Host 2| |Host 3|
+------+ +------+ +------+
]]></artwork>
</figure>
<figure anchor="figure2" title="Sample remote session">
<artwork align="center"><![CDATA[
/---+--------+-------+---/
| | |
+---+--+ +---+--+ +--+---+
|Host 1| | RTR 1| |Host 3|
+------+ +---+--+ +------+
|
/
|
+---+--+
| RTR 2|
+---+--+
|
/---+-----+---/
|
+---+--+
|Host 2|
+------+
]]></artwork>
</figure>
<t>Host 1 properly allocates an address by whatever means including
manual configuration, DHCPv6, SeND, or ND, and uses the address to open
a session with Host 2. The fact that it has allocated the address is
observed by Host 3, perhaps by receipt of a Neighbor Solicitation during
Duplicate Address Detection.</t>
<t>Host 1 now experiences a link-down event, losing the use of the
address. This might be because the switch rebooted, Host 1's
connectivity to the LAN was temporarily lost, or because Host 1 itself
failed.</t>
<t>Host 3 now issues a Neighbor Solicitation for Host 1's address, and
because Host 1 has lost its memory of the address or is unavailable at
the time the request goes out. It has therefore correctly allocated the
address to itself.</t>
<t>In this case, it would appear that the session between Host 1 and
Host 2 is transferred, so that it is now between Host 2 and Host 3.</t>
</section>
<section anchor="mitigations" title="Possible mitigations">
<t>First one should note that in a cloud computing environment this may
be an intended behavior. If it is unintended, it constitutes an
attack.</t>
<t>There are a number of possible mitigations: <list style="symbols">
<t>Obviously, if the hosts have any form of session security
including IPsec AH, IPsec ESP, TLS, etc, the applications will be
prevented from communicating. Host 3 will still, however, be aware
that the sessions existed.</t>
<t>Neighbor Discovery could be augmented to prevent movement of the
IPv6 address from one MAC Address to another without an
application-obvious hiccup.</t>
<t>If a SAVI switch is in use, the SAVI behavior could similarly be
extended to prevent the movement of the address from Host 1 to Host
3 without an application-obvious hiccup.</t>
</list></t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This memo asks the IANA for no new parameters.</t>
<t>Note to RFC Editor: This section will have served its purpose if it
correctly tells IANA that no new assignments or registries are required,
or if those assignments or registries are created during the RFC
publication process. From the author"s perspective, it may therefore be
removed upon publication as an RFC at the RFC Editor"s discretion.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>This note augments <xref target="RFC3756"></xref>, and constitutes a
security consideration.</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>The observation came out of a discussion regarding threats in a SAVI
environment, among the author, Jun Bi, Guang Yao, and Eric
Levy-Abegnoli.</t>
</section>
</middle>
<back>
<!-- references split to informative and normative -->
<references title="Normative References">
<?rfc include='reference.RFC.2460' ?>
</references>
<references title="Informative References">
<?rfc include='reference.RFC.3756' ?>
<?rfc include='reference.RFC.4861' ?>
<?rfc include='reference.RFC.3971' ?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 02:57:20 |