Re: [Int-area] Route Information Options in Redirect Messages

Zied Bouziri <> Wed, 11 January 2017 21:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8A92C1295A7; Wed, 11 Jan 2017 13:47:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0Z1dszB3MIV8; Wed, 11 Jan 2017 13:47:52 -0800 (PST)
Received: from ( [IPv6:2a00:1450:400c:c01::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3E6DD12950E; Wed, 11 Jan 2017 13:47:52 -0800 (PST)
Received: by with SMTP id dh1so83890wjb.3; Wed, 11 Jan 2017 13:47:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=SSRZkOzCTlMUwft72yrOysL8kCRvX4I3INUEuwcRd4o=; b=siNW+83qRz4/OQh6FIAm/c6NmrrkAuw75yMBGIX7JX4pqON6uwOtZyEphvg2FS4C8V rr1+enfDWuF0oS9TYhlGzJ2VYe4huXqjoaUo5hhOBaI8D0sVxFZB5FVK7XNNip43PhX3 Y8E74KS8qK72CVFZmrK8zlG+5hc9cnhpEbSZAowA1q4CCtW4YWidAyijNV8kNtMxfzOL n5Bc+xF8TT4CMobnY1EVM3EQeAHqopJqzFIaOXo1z3qNwHBo7VMvAv1mbXlKEL0ID6Cm vi+D5CCxN/3jQsWf9fhvTqu6yvWvxOBqNVyKIHlqVWKwoS8VLN9gLoDETZ3mi32EaP8u bb5g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=SSRZkOzCTlMUwft72yrOysL8kCRvX4I3INUEuwcRd4o=; b=ley669ezerED6Io1GVJhPaHnpMHCzu+rEFwtW8VXk5nKUWY2kVoY3PqtA0Yku78oti /a4vTieSu83ko5JCdCd2frQzQksX2MG98bBAzNtOkUhfzV0anry1+/u4cvh7WCsaSLdf jkTeYLVPy4FpFSXQFxH06uvpzyf8yqCxJAu6AR8v2846xf6E30AjCV9hi95UDSZXQjGe zcrRPQson1u/bUTbdGj9jNN75sz+hsM/7cUZxXmZ2lSk6UKaj0DMR/sGoP9w8rGuVctA Hn8hVaonm5SwFYDlNEAvO4BBqB1ghLMcS2YkN6W5R6MiKvzQqwJh5SZaFT6MgULjpnk/ sQAw==
X-Gm-Message-State: AIkVDXIf5uhEFyFJBZdrhpHBQkREVRHGaCH6iFVrwM+S49RLEuEZNO+yfxauIzqUP7EVBA==
X-Received: by with SMTP id ht8mr6680198wjb.36.1484171270677; Wed, 11 Jan 2017 13:47:50 -0800 (PST)
Received: from [] ([]) by with ESMTPSA id k11sm10893900wmb.18.2017. (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 11 Jan 2017 13:47:49 -0800 (PST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_03BAFB09-429E-4614-BCDE-0F6311BE5072"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
Subject: Re: [Int-area] Route Information Options in Redirect Messages
From: Zied Bouziri <>
In-Reply-To: <>
Date: Wed, 11 Jan 2017 22:47:46 +0100
Message-Id: <>
References: <> <> <> <016f01d26b78$870895a0$9519c0e0$> <>
To: "Templin, Fred L" <>
X-Mailer: Apple Mail (2.2104)
Archived-At: <>
Cc: 6man WG <>, INT Area <>, Christian Huitema <>
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 11 Jan 2017 21:47:55 -0000

Hi Fred
In section 6 :
"Namely, the protocol must take measures to secure IPv6 ND messages on links where spoofing attacks are possible »
By reading this passage, I have the impression that there are links where attack spoofing is possible and others not !
How can we know if this attack is possible or not in a specified link ?
Thank you 

> Le 10 janv. 2017 à 22:52, Templin, Fred L <> a écrit :
> Hi Christian,
>> -----Original Message-----
>> From: Christian Huitema []
>> Sent: Tuesday, January 10, 2017 11:34 AM
>> To: Templin, Fred L <>om>; 'Brian E Carpenter' <>om>; '6man WG' <>rg>;
>> 'INT Area' <>
>> Subject: RE: [Int-area] Route Information Options in Redirect Messages
>> On Tuesday, January 10, 2017 9:55 AM, Fred Templin wrote:
>>> ...
>>> What is being proposed in the document I submitted is the inclusion of
>>> RIOs in Redirect messages for a *prefix* that is not on-link, as opposed
>>> to a singleton destination. So, the same SHOULD in the paragraph above
>>> would seem to apply also to prefix redirection the same as for ordinary
>>> destination redirection.
>> Fred, I am reading the security section of your draft. I think it needs a
>> bit more work.
>> Currently, the RIO are only expected in router advertisements. RA are
>> somewhat special, and there is often specific code in switches to check RA
>> and prevent RA spoofing -- e.g., RA-Guard. Allowing the option in Redirect
>> messages could very well bypass the RA specific checks. Doesn't that open
>> the path for new attacks? Should you not say something about that in the
>> security section? How about specific mitigations, such as sanity checks when
>> processing redirect messages?
> Since IP will still operate correctly if transmission of Redirect messages is
> somehow suppressed (i.e., denial of Redirect service), the more serious
> threat to be considered is spoofing. Here is what currently appears under
> Security Considerations:
>   "Security considerations for Redirect messages that include RIOs are
>   the same as for any IPv6 ND messages as specified in Section 11 of
>   [RFC4861].  Namely, the protocol must take measures to secure IPv6 ND
>   messages on links where spoofing attacks are possible.
>   A spoofed Redirect message containing no RIOs could cause corruption
>   in the host's destination cache while a spoofed Redirect message
>   containing RIOs could corrupt the host's routing tables.  While the
>   latter would seem to be a more onerous result, the possibility for
>   corruption is unacceptable in either case."
> So, from the first paragraph, we can see that the protocol must take
> measures to secure IPv6 ND messages on links where spoofing attacks
> are possible. The second paragraph then analyzes the consequences of
> what could happen if a spoofing attack were successful and we see that
> there are unacceptable negative consequences for both traditional
> Redirects and Redirects that include RIOs.
> The text stops short of saying that "no Redirects of any kind should be
> used on links where spoofing attacks are possible". Would adding a
> statement such as this address the concern?
> Thanks - Fred
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> Administrative Requests:
> --------------------------------------------------------------------

Best Regards, مع تحياتي
Zied BOUZIRI، زياد بوزيري
ISET Charguia, Tunisie <>