Geoff and Chris,
But trying to erase the capability itself from the protocol standard
smacks to me of overreaction, and in terms of the security and safety of
the internet is another classic example of security pantomime!
[But, like Chris, in thinking these evil thoughts I'm now a heretic.
Christopher Morrow wrote:
On 6/14/07, Thomas Narten [EMAIL PROTECTED] wrote:
If we want the advice in this section to be taken seriously, do we
need to distinguish between firewall policy in end-sites and packet
filters that might be added to core/ISP networks as a mitigation of
the
On 6/14/07, Thomas Narten [EMAIL PROTECTED] wrote:
If we want the advice in this section to be taken seriously, do we
need to distinguish between firewall policy in end-sites and packet
filters that might be added to core/ISP networks as a mitigation of
the specific problems associated
On 6/15/07, james woodyatt [EMAIL PROTECTED] wrote:
For my part, I'd rather not try to answer this question. If pressed,
I would say that such a device ought not try to be a filter at all.
If that's not possible, then the device should permit all routing
headers. More damage will be done by
On 16-Jun-2007, at 02:23, Christopher Morrow wrote:
I'd actually be a fan of not deprecating the headers in question, but
permitting implementations to either ignore+forward, drop, use them.
So, in the case at hand an operator could decide that 'source routing
is ok' on their network and
Le samedi 16 juin 2007, Ole Troan a écrit :
To be clear, if even a small fraction of firewalls get deployed
that just block all traffic with a RH, MIPv6 breaks and becomes
undeployable in practice. For EVERYONE!
The answer to the upcoming question must be obvious to many people
On 2007-06-15 03:53, james woodyatt wrote:
On Jun 14, 2007, at 18:27, Thomas Narten wrote:
I understand that the default security policy/config is just say no.
But if we accept that, in this case, then I think the implication
really is we might as well toss out the routing header entirely.
On Thu, 14 Jun 2007 17:09:09 -0700, Thomas Narten [EMAIL PROTECTED]
wrote:
I'm slightly concerned that such advice flies in the face of
conventional advice given to those constructing firewall policy. It
is normal practice, I believe, for end-site firewall policy to be
deployed based on
-Original Message-
From: james woodyatt [mailto:[EMAIL PROTECTED]
Sent: Thursday, June 14, 2007 21:53
To: IETF IPv6 Mailing List
Subject: Re: draft-ietf-ipv6-deprecate-rh0-01-candidate-01
On Jun 14, 2007, at 18:27, Thomas Narten wrote:
I understand that the default security policy
TJ wrote:
[..]
For clarification - let's say we have a device that can filter based on the
presence of a routing header, but cannot be more granular and filter based
on what type of routing header it is.
Then that device's IPv6 implementation is inherently broken. This, as
with the current
If you need to choose either accepting or blocking all routing
headers, which do you recommend to your (potentially very paranoid,
and that isn't necessarily bad) clients?
RH2 are harmless and are only supported by Mobile IPv6 aware nodes
(Mobile Nodes, and Correspondent Nodes supporting
Is the recommendation be to fail closed - block all RHs, including
Type2, thus breaking Route Optimization?
If you block all RHs, you break Mobile IPv6 and not only the Route
Optimization.
The RH2 is used to *carry* the Binding Acknowledgment from the home
agent to the mobile node.
of doing more granular
filtering ... but this isn't just a hypothetical situation :))
/TJ
-Original Message-
From: Guillaume Valadon / ギョーム バラドン
[mailto:[EMAIL PROTECTED]
Sent: Friday, June 15, 2007 08:29
To: [EMAIL PROTECTED]
Cc: 'IETF IPv6 Mailing List'
Subject: Re: draft-ietf-ipv6
How about if I say traffic amplification over a remote path instead
of packet amplification?
wfm.
Seems like a sentence or two describing the exploitation itself would
be good. Not a lot of detail, but more than just it can be
exploited. (Later, I see that you include such text in the
=?windows-1252?q?R=E9mi_Denis-Courmont?= [EMAIL PROTECTED] writes:
Le mercredi 13 juin 2007, Thomas Narten a écrit :
To be clear, if even a small fraction of firewalls get deployed that
just block all traffic with a RH, MIPv6 breaks and becomes
undeployable in practice. For EVERYONE!
-ietf-ipv6-deprecate-rh0-01-candidate-01
=?windows-1252?q?R=E9mi_Denis-Courmont?= [EMAIL PROTECTED]
writes:
Le mercredi 13 juin 2007, Thomas Narten a écrit :
To be clear, if even a small fraction of firewalls get deployed
that
just block all traffic with a RH, MIPv6 breaks and becomes
On Jun 15, 2007, at 05:20, TJ wrote:
For clarification - let's say we have a device that can filter
based on the
presence of a routing header, but cannot be more granular and
filter based
on what type of routing header it is.
Is the recommendation be to fail closed - block all RHs,
-Original Message-
From: Thomas Narten [mailto:[EMAIL PROTECTED]
The answer to the upcoming question must be obvious to many
people here,
but anyway not to me: Does blocking RH2 breaks Mobile Nodes in your
network, or does it break both Mobile Nodes *AND* Correspondant
Le vendredi 15 juin 2007, Manfredi, Albert E a écrit :
Hence, if such filtering becomes even occasionaly common on the
open Internet, MIPv6 will become unusable/undeployable in practice.
If you mean ISPs, I agree. If you mean home nets, it doesn't matter
so much. The home user can simply be
Hi,
Le 13 juin 07 à 19:53, Rémi Denis-Courmont a écrit :
Le mercredi 13 juin 2007, Thomas Narten a écrit :
To be clear, if even a small fraction of firewalls get deployed that
just block all traffic with a RH, MIPv6 breaks and becomes
undeployable in practice. For EVERYONE!
The answer to
On 2007-06-13 23:37, Joe Abley wrote:
On 13-Jun-2007, at 10:42, Thomas Narten wrote:
Firewall policy intended to protect against packets containing RH0
must be constructed such that routing headers of other types
are not filtered by default. Doing so will break other uses of
I'm slightly concerned that such advice flies in the face of
conventional advice given to those constructing firewall policy. It
is normal practice, I believe, for end-site firewall policy to be
deployed based on denying everything by default, and only permitting
those packets which
On 14-Jun-2007, at 17:09, Thomas Narten wrote:
I'm slightly concerned that such advice flies in the face of
conventional advice given to those constructing firewall policy. It
is normal practice, I believe, for end-site firewall policy to be
deployed based on denying everything by default, and
I think you are missing my point.
I don't think so (though I may have been overly sarcastic in my
response). I understand that the default security policy/config is
just say no.
But if we accept that, in this case, then I think the implication
really is we might as well toss out the routing
On Jun 14, 2007, at 18:27, Thomas Narten wrote:
I understand that the default security policy/config is just say no.
But if we accept that, in this case, then I think the implication
really is we might as well toss out the routing header entirely.
[...]
We already did accept that as the
On 14-Jun-2007, at 18:27, Thomas Narten wrote:
I think you are missing my point.
I don't think so (though I may have been overly sarcastic in my
response). I understand that the default security policy/config is
just say no.
OK, good then. Sorry for mischaracterising your reply.
I think
On Thu, 14 Jun 2007, Joe Abley wrote:
I think you are missing my point.
I don't think so (though I may have been overly sarcastic in my
response). I understand that the default security policy/config is
just say no.
OK, good then. Sorry for mischaracterising your reply.
I think there is a
Here's a revised candidate -01. As before, I have not submitted this
to the i-d repository, but offer it here first instead in order to
make sure my changes seem reasonable.
(snip)
I'm very happy with the 01-candidate-01. concise, straight to the
point.
itojun
I am happy with the revisions.
Best,
George
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Joe,
The next to last sentence is a bit weak. Dropping all packets with
routing headers will flat-out break MIPv6. If routers/firewalls start
doing that, that would be very bad. From a standards perspecive, we
should clearly flag that as bad/non compliant.
If I understand your point, you are
Bob Hinden wrote:
[..]
I agree with Thomas that it is important to state this very clearly.
How about something like this:
Firewall policy intended to protect against packets containing RH0
must be constructed such that routing headers of other types
are not filtered by default.
Bob Hinden [EMAIL PROTECTED] writes:
I agree with Thomas that it is important to state this very
clearly.
To be clear, if even a small fraction of firewalls get deployed that
just block all traffic with a RH, MIPv6 breaks and becomes
undeployable in practice. For EVERYONE!
MIPv6 can't work
Le mercredi 13 juin 2007, Thomas Narten a écrit :
To be clear, if even a small fraction of firewalls get deployed that
just block all traffic with a RH, MIPv6 breaks and becomes
undeployable in practice. For EVERYONE!
The answer to the upcoming question must be obvious to many people here,
Thomas,
Could be even stronger. How about:
It must be understood that blocking all traffic with any RH
(rather than restricting blockage only to type 0) has very
serious implications for the deployment of future
technology. Quite simply, if even a small percentage of
On 13-Jun-2007, at 10:09, Jeroen Massar wrote:
I have one teeny thing that I think would be worthwhile repeating in
that document: Please enable uRPF where possible as that actually
already takes care of the most of the problem as packets can't go
where
they are not able to come from.
Is
Joe Abley wrote:
On 13-Jun-2007, at 10:09, Jeroen Massar wrote:
I have one teeny thing that I think would be worthwhile repeating in
that document: Please enable uRPF where possible as that actually
already takes care of the most of the problem as packets can't go where
they are not able
On 13-Jun-2007, at 10:42, Thomas Narten wrote:
Firewall policy intended to protect against packets containing
RH0
must be constructed such that routing headers of other types
are not filtered by default. Doing so will break other uses of
the routing headers such as the
On 13-Jun-2007, at 14:33, Jeroen Massar wrote:
Joe Abley wrote:
On 13-Jun-2007, at 10:09, Jeroen Massar wrote:
I have one teeny thing that I think would be worthwhile repeating in
that document: Please enable uRPF where possible as that actually
already takes care of the most of the
Joe Abley wrote:
On 13-Jun-2007, at 14:33, Jeroen Massar wrote:
Joe Abley wrote:
On 13-Jun-2007, at 10:09, Jeroen Massar wrote:
I have one teeny thing that I think would be worthwhile repeating in
that document: Please enable uRPF where possible as that actually
already takes care of
At Wed, 13 Jun 2007 04:53:50 -0700,
Thomas Narten [EMAIL PROTECTED] wrote:
Abstract
The functionality provided by IPv6's Type 0 Routing Header can be
exploited in order to achieve packet amplification for the purposes
of generating denial-of-service traffic. This document
40 matches
Mail list logo