> > my take on this is that, for non-final fragment, the packet size must
> > not be smaller than 1280 bytes. there's no valid use for smaller
> > fragments (unless you have special network with MTU < 1280).
> I agree to the solution. If we get more people talking about the need
> for this, we
Hi Itojun,
I agree to the solution. If we get more people talking about the need
for this, we can actually revive the draft.
Thanks,
Vishwas
On 5/17/07, Jun-ichiro itojun Hagino 2.0 <[EMAIL PROTECTED]> wrote:
> At the time of bringing up the amplification attacks i had also
> brought up the is
> At the time of bringing up the amplification attacks i had also
> brought up the issue of
> http://tools.ietf.org/html/draft-manral-v6ops-tiny-fragments-issues-02 .
>
> I would want to know if this issue needs to looked further by IPv6.
my take on this is that, for non-final fragment, t
Hi,
At the time of bringing up the amplification attacks i had also
brought up the issue of
http://tools.ietf.org/html/draft-manral-v6ops-tiny-fragments-issues-02 .
I would want to know if this issue needs to looked further by IPv6.
Thanks,
Vishwas
-
> > I added a reference to the ipv6 security draft.
> I had brought out this amplification attack way back in January of
> 2006 though without the big RED flags, that is the reason I wanted to
> own up the responsibility. :))
i've got a comment from IPv6 ready logo team (iirc it is sub-co
Hi Joe,
Thanks.
I had brought out this amplification attack way back in January of
2006 though without the big RED flags, that is the reason I wanted to
own up the responsibility. :))
Thanks again,
Vishwas
On 5/16/07, Joe Abley <[EMAIL PROTECTED]> wrote:
On 16-May-2007, at 08:08, Vishwas Man
On Wed, May 16, 2007 at 05:09:34PM -0500, Tim Enos wrote:
> In section 4.2, IMO it would seem good to see a brief justification of
> the statement: "filtering based on the presence of any
>Routing Headers on IPv6 routers, regardless of type, is strongly
>discouraged."
In this sentence, is
On Wed, May 16, 2007 at 03:54:48PM -0700, Dow Street wrote:
> I think the new draft is too extreme in its mitigation approach, and
> would favor the "disable by default" option instead.
I think the new draft is too soft in it's mitigation approach, and would
favour language that more strongly enco
On 17-mei-2007, at 3:29, Joe Abley wrote:
There is an argument that the right approach to facilitate source
routing experiments is to deprecate RH0, and define a new type of
routing header which is, from the outset, disabled by default.
Please present this argument; it's not self-evident.
> There is an argument that the right approach to facilitate source routing
> experiments is to deprecate RH0, and define a new type of routing header
> which is, from the outset, disabled by default.
yes please.
IETF IPv6 wor
On 16-May-2007, at 18:54, Dow Street wrote:
It may not be the mechanism itself that is the inherent problem,
but rather the operational use model. In this case, disabling by
default and filtering when RH0 is turned on allows for careful
investigation and experimentation of different use m
> Not sure why this hasn't gotten to the list yet, but here it is again.
> >
> > Title : Deprecation of Type 0 Routing Headers in IPv6
> > Author(s) : J. Abley, et al.
> > Filename: draft-ietf-ipv6-deprecate-rh0-00.txt
> > Pages : 7
> > Date
I think the new draft is too extreme in its mitigation approach, and
would favor the "disable by default" option instead.
Underlying this debate seems to be the question of whether *any* form
of source routing is ok / worthwhile. I'm curious how much of the
RH0 FUD is actually related to t
Hi Bob/all,
Having read the new draft, I think it is a great first pass. The References
used are IMO both thorough and relevant.
In section 4.1, IMO it would seem good to see an example each of what RH0 uses
[a]would and [b]would not be mitigated via BCP 38/84 implementation.
In section 4.2,
As part of the deprecation effort, does it also make sense to
update RFC 3542 (Advanced API) to remove the references to Type 0
routing header?
Thanks
-vlad
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Reque
Not sure why this hasn't gotten to the list yet, but here it is again.
Bob
Begin forwarded message:
From: "ext [EMAIL PROTECTED]" [EMAIL PROTECTED]>
Date: May 16, 2007 12:50:02 PM PDT
To: [EMAIL PROTECTED]
Cc: ipv6@ietf.org
Subject: I-D ACTION:draft-ietf-ipv6-deprecate-rh0-00.txt
Reply-To: [E
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the IP Version 6 Working Group Working Group of
the IETF.
Title : Deprecation of Type 0 Routing Headers in IPv6
Author(s) : J. Abley, et al.
Filena
On 16-mei-2007, at 17:17, Joe Abley wrote:
http://www.flapdoodle.org/draft-ietf-ipv6-deprecate-rh0-00.txt
I object to the use of the word "security". More later.
IETF IPv6 working group mailing list
ipv6@ietf.org
Administr
On 16-mei-2007, at 16:51, Tim Enos wrote:
Should (can) something like the following be added to the draft ?:
"Conformant implementations of IPv6 hosts and routers MUST not
provide a way to activate RH0 processing on the system."
This is a very bad idea for two reasons:
1. The IPv6 spec say
On 14-May-2007, at 16:12, Brian Haberman wrote:
The chairs request that the authors of the two two drafts
currently
published discussing the RH0 issue (draft-jabley-ipv6-rh0-is-
evil-00.txt
and draft-savola-ipv6-rtheader-00.txt) combine them and publish a
single
draft as an IPv6 w.g.
On 16-May-2007, at 08:08, Vishwas Manral wrote:
I noticed the draft and saw the use of the term amplification attacks
with respect to IPv6 Type0 Routing header.
I had brought up the issue as well as used the term way back in
January 2006.
http://psg.com/lists/v6ops/v6ops.2006/msg1.html
>As for intercontinental links: as an ISP, I wouldn't mind my
>customers ping-ponging the same packet back and forth: this uses more
>bandwidth, so I make more money.
Given the potential for degradation of service (if not outright DoS) via a
sufficient # of ping-ponged packets (bw loss), th
Hi Iljitsch/all,
>On 16-mei-2007, at 10:05, Ebalard, Arnaud wrote:
>
>> Should (can) something like the following be added to the draft ?:
>> "Conformant implementations of IPv6 hosts and routers MUST not
>> provide a way to activate RH0 processing on the system."
>
>This is a very bad idea for tw
On 16-May-2007, at 04:05, Ebalard, Arnaud wrote:
Should (can) something like the following be added to the draft ?:
"Conformant implementations of IPv6 hosts and routers MUST not
provide a way to activate RH0 processing on the system."
I think this is inherent in the whole concept of deprecat
On 16-mei-2007, at 14:59, Paul Vixie wrote:
This whole issue is blown WAY out of proportion: the BSD guys should
not forward when forwarding is disabled, the router guys should
disable source routing by default (for IPv4, too, please). Problem
solved, bring on the next one.
that won't solve th
> >> Should (can) something like the following be added to the draft ?:
> >> "Conformant implementations of IPv6 hosts and routers MUST not
> >> provide a way to activate RH0 processing on the system."
> >
> > This is a very bad idea for two reasons:
i disagree with both, as shown below.
> > 1. T
[sorry for cross-posting]
Hello,
FYI the following I-D suggests replacing the phone book
for cellular phones, with an end-to-end approach
(cell phone number is requested from the target cell phone).
http://www.ietf.org/internet-drafts/draft-mutaf-piqproblem-01.txt
-Problem statement probably do
Hi,
I noticed the draft and saw the use of the term amplification attacks
with respect to IPv6 Type0 Routing header.
I had brought up the issue as well as used the term way back in January 2006.
http://psg.com/lists/v6ops/v6ops.2006/msg1.html . It was later
incorporated in the "IPv6 security
>> Should (can) something like the following be added to the draft ?:
>> "Conformant implementations of IPv6 hosts and routers MUST not
>> provide a way to activate RH0 processing on the system."
>
> This is a very bad idea for two reasons:
>
> 1. The IPv6 spec says that you MUST implement it, then
> > as posted earlier, i cannot really sleep tight until the very last
> > machine on the planet get patched. root DNS servers as well as all
> > trans-ocean links (both IPv4 and IPv6) are at stake. if this does
> > not
> > scare you enough, quit your job immediately.
>
> Well,
On 16-mei-2007, at 13:06, Jun-ichiro itojun Hagino 2.0 wrote:
as posted earlier, i cannot really sleep tight until the very last
machine on the planet get patched. root DNS servers as well as all
trans-ocean links (both IPv4 and IPv6) are at stake. if this does
not
On 16-mei-2007, at 13:01, Jun-ichiro itojun Hagino 2.0 wrote:
2. Maybe someone has a legitimate use for this, they should be able
to do so if they want
how many times do i have to post this: there's ZERO RFCs that use
rthdr0.
Since when is it required to write an RFC before
> > > Should (can) something like the following be added to the draft ?:
> > > "Conformant implementations of IPv6 hosts and routers MUST not
> > > provide a way to activate RH0 processing on the system."
> >
> > This is a very bad idea for two reasons:
> >
> > 1. The IPv6 spec says that you MUST
> On 16-mei-2007, at 10:05, Ebalard, Arnaud wrote:
>
> > Should (can) something like the following be added to the draft ?:
> > "Conformant implementations of IPv6 hosts and routers MUST not
> > provide a way to activate RH0 processing on the system."
>
> This is a very bad idea for two reasons:
On 16-mei-2007, at 10:05, Ebalard, Arnaud wrote:
Should (can) something like the following be added to the draft ?:
"Conformant implementations of IPv6 hosts and routers MUST not
provide a way to activate RH0 processing on the system."
This is a very bad idea for two reasons:
1. The IPv6 spec
Hi,
Le 14 mai 07 à 22:12, Brian Haberman a écrit :
> Please make any issues/problems you may have with this approach
> known to either the mailing list or the chairs directly.
The following point is being discussed off-list and there is
certainly interest in having a clear statement on th
36 matches
Mail list logo
