Simon Perreault simon.perrea...@viagenie.ca writes:
Correct. But if DHCP or RAs are not filtered at layer 2, a rogue user
can already do this today without this extension.
Right, to a certain extent that is true, of course; but not in the same
drive-by fashion where a single packet can put
Le 2014-04-15 07:28, Toke Høiland-Jørgensen a écrit :
Simon Perreault simon.perrea...@viagenie.ca writes:
Correct. But if DHCP or RAs are not filtered at layer 2, a rogue user
can already do this today without this extension.
Right, to a certain extent that is true, of course; but not in
Simon Perreault simon.perrea...@viagenie.ca writes:
Sure it can. Just send them to a non-existing default gateway. Unless
I misunderstood your point.
My point was that if you do this, the next time the real gateway sends
out an advertisement, connections are going to be restored. Whereas if
In your letter dated Tue, 15 Apr 2014 09:46:38 -0400 you wrote:
Le 2014-04-15 07:28, Toke H=F8iland-J=F8rgensen a =E9crit :
Simon Perreault simon.perrea...@viagenie.ca writes:
=
Correct. But if DHCP or RAs are not filtered at layer 2, a rogue user
can already do this today without this
We are soliciting reviews for this SUNSET4 draft:
http://tools.ietf.org/html/draft-ietf-sunset4-noipv4-00
In a nutshell, it defines DHCPv6 and RA options indicating to the host
that IPv4 is not available.
It seems to me that options relating to IPv4 don't belong in RA/DHCPv6
-- they belong
On Apr 15, 2014, at 6:28 AM, Toke Høiland-Jørgensen t...@toke.dk wrote:
Right, to a certain extent that is true, of course; but not in the same
drive-by fashion where a single packet can put everyone offline (if the
option is not in the regular announcements).
This is a good point. Given
On Apr 15, 2014, at 9:07 AM, Juliusz Chroboczek
j...@pps.univ-paris-diderot.fr wrote:
Having a degenerate DHCPv4 server that just
NAKs every request would appear to solve all of the problems in Section 3.
Actually no, this would create packet storms.
Le 2014-04-15 09:56, Philip Homburg a écrit :
Right, to a certain extent that is true, of course; but not in the same
drive-by fashion where a single packet can put everyone offline (if the
option is not in the regular announcements).
Sure it can. Just send them to a non-existing default
Le 2014-04-15 11:17, Ted Lemon a écrit :
On Apr 15, 2014, at 9:07 AM, Juliusz Chroboczek
j...@pps.univ-paris-diderot.fr wrote:
Having a degenerate DHCPv4 server that just
NAKs every request would appear to solve all of the problems in Section 3.
Actually no, this would create packet
On 15.4.2014, at 17.07, Juliusz Chroboczek j...@pps.univ-paris-diderot.fr
wrote:
We are soliciting reviews for this SUNSET4 draft:
http://tools.ietf.org/html/draft-ietf-sunset4-noipv4-00
In a nutshell, it defines DHCPv6 and RA options indicating to the host
that IPv4 is not available.
Le 2014-04-15 11:15, Ted Lemon a écrit :
On Apr 15, 2014, at 6:28 AM, Toke Høiland-Jørgensen t...@toke.dk wrote:
Right, to a certain extent that is true, of course; but not in the same
drive-by fashion where a single packet can put everyone offline (if the
option is not in the regular
Ted Lemon mel...@fugue.com writes:
No, because this just leaves the client open to a different DoS
attack. If you have rogue configuration protocols running on your
network, you need to fix it. This just moves the problem around—it
doesn't solve it.
Well, assuming this stays as an RA option
In your letter dated Tue, 15 Apr 2014 11:24:48 -0400 you wrote:
Le 2014-04-15 09:56, Philip Homburg a écrit :
Right, to a certain extent that is true, of course; but not in the same
drive-by fashion where a single packet can put everyone offline (if the
option is not in the regular
Le 2014-04-15 11:48, Philip Homburg a écrit :
In your letter dated Tue, 15 Apr 2014 11:24:48 -0400 you wrote:
Le 2014-04-15 09:56, Philip Homburg a écrit :
Right, to a certain extent that is true, of course; but not in the same
drive-by fashion where a single packet can put everyone offline
On Apr 15, 2014, at 10:34 AM, Simon Perreault simon.perrea...@viagenie.ca
wrote:
Makes total sense. Will be added in the next revision.
What about the other part?
I think it works with the use model you have in mind: if you want some devices
to do IPv4 and others not, you can advertise no
Sorry, missed an important part. Replying in full.
Le 2014-04-15 11:15, Ted Lemon a écrit :
On Apr 15, 2014, at 6:28 AM, Toke Høiland-Jørgensen t...@toke.dk wrote:
Right, to a certain extent that is true, of course; but not in the same
drive-by fashion where a single packet can put everyone
On Apr 15, 2014, at 10:46 AM, Toke Høiland-Jørgensen t...@toke.dk wrote:
As an example, consider a university campus network (or a conference
network) running IPv4 only, and someone broadcasting an RA packet onto
the open wireless. Suddenly everything goes offline and will stay that
way (until
On Apr 15, 2014, at 11:05 AM, Simon Perreault simon.perrea...@viagenie.ca
wrote:
Yes, and by the time this is fully configurable, you are talking about many
hundreds lines of code.
I completely disagree with your estimate.
I think you are talking apples and oranges. Simon, you are
On Apr 15, 2014, at 11:22 AM, Simon Perreault simon.perrea...@viagenie.ca
wrote:
So that means if you're running DHCPv6, and assuming you use RAs for
provisioning at least the default gateway, you need to put the No-IPv4
option in both RA and DHCPv6. If we specify that then we could just kill
Le 2014-04-15 12:25, Ted Lemon a écrit :
On Apr 15, 2014, at 11:22 AM, Simon Perreault simon.perrea...@viagenie.ca
wrote:
So that means if you're running DHCPv6, and assuming you use RAs for
provisioning at least the default gateway, you need to put the No-IPv4
option in both RA and DHCPv6.
In your letter dated Tue, 15 Apr 2014 12:05:59 -0400 you wrote:
http://resources.infosecinstitute.com/slaac-attack/
When you have unfiltered L2 access, there are LOTS of evil things you
can do.
The world is not black and white. Rogue RAs are easy for hit and run attacks.
Maybe I should already
I think it's important to read the draft, and understand section 5.3,
about the v4-level.
I think that the security implications in the document are understood by the
authors, but simply not spelled out yet.
I think that some additional text in 5.3 might help make it
clearer that there might be
In your letter dated Tue, 15 Apr 2014 11:24:31 -0500 you wrote:
I think you are talking apples and oranges. Simon, you are assuming a functio
nal configuration environment; in such an environment, the change would be fair
ly trivial. Philip, I think you are assuming the current status quo on
Having a degenerate DHCPv4 server that just NAKs every request
would appear to solve all of the problems in Section 3.
Actually no, this would create packet storms.
My bad -- I didn't actually check.
So either an empty OFFER, as suggested by Markus, or an OFFER with
a new *DHCPv4* option.
On Apr 15, 2014, at 11:47 AM, Philip Homburg pch-homene...@u-1.phicoh.com
wrote:
On the other hand, if you need have RAs signal suspend and resume of IPv4
you are looking at rewriting the management code of lots of different Linux
distibutions (including various embedded ones) and many
In your letter dated Tue, 15 Apr 2014 12:09:48 -0500 you wrote:
On Apr 15, 2014, at 11:47 AM, Philip Homburg pch-homene...@u-1.phicoh.com wro
te:
On the other hand, if you need have RAs signal suspend and resume of IPv4
you are looking at rewriting the management code of lots of different Linux
I'm only saying that from my perspective, changing DHCPv4 is the best
technical solution.
Right, but you haven't given a technical argument to support that.
You're being somewhat disingeneous here, Ted.
We're arguing that information about IPv4 availability should not be
carried by IPv6
In message m1wabgi-...@stereo.hq.phicoh.net, Philip Homburg writes:
In your letter dated Tue, 15 Apr 2014 13:20:19 -0500 you wrote:
Right, but you haven't given a technical argument to support that.
You've just said that it's convenient in a particular existing
implementation, which
slowly I've gotten to understand the numerous layer-2 and layer-3
savings by not having to have the whole DHCPv4 relay and broadcast
processing occuring.
Could you please explain that? Perhaps with some examples, or even
actual empirical data?
-- Juliusz
29 matches
Mail list logo
