>We need some diagrams that we can all agree upon, and we need to name the
>different observers.
>
>Each thing defends against different kinds of observers, and not all
>observers can see all things.
Observer may be the wrong term, the more standard term is attack scenario.
Some attacks are
>>> Yeah, the so-called "TTL hack".
>
>> Care to explain why it would not be useful?
>
>At the time I wrote down Babel, I decided that given that we have link-local
>addresses that are securely scoped to a single link, the TTL hack is not
>necessary.
The TTL hack is used in ND. It strikes me as
>Yeah, the so-called "TTL hack".
Care to explain why it would not be useful?
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
In your letter dated Wed, 26 Jul 2017 20:49:10 +0200 you wrote:
>> Historically, a popular brand of router would forward packets with LL source
>.
>
>"Historically"? Has this been fixed?
I wanted to give them the benefit of the doubt. Sometimes they do fix a bug
and I didn't want to spend any
>Nasty comments on list, please, compliments by private mail ;-)
A trick used in some places, such as ND, is to require the receiver to check
that the hop limit is equal to 255. This ensures that the packet has not
been forwarded by any router (obviously the sender also has to send it with
a hop
Some remarks regarding draft-pfister-homenet-dot-00:
(I'll ignore the specific value '.homenet')
Section 2:
"or only reachable from within the home
"network (e.g., a web server hosted by the service provider and
"providing a service that is specific to the home)."
I think it is best to drop
>You write TLS, but really, I think you mean PKIX (certificates).
>AFAIK, TLS with raw public key or PSK doesn't care about time.
>
>While this might be a pedantic point, I think it's important to be clear
>about where the problem is because it reveals that there are TLS uses which
>do not have
>Which in some implementations, means having a clock to know that your current
>firmware is actually newer than the "proposed" new firmware (which is really
>much older), or knowing that it's been too long since a firmware load.
Where I entered the discussion is basically saying that only way to
>>> ddos attack like against Dyn
>
>I could be wrong, but I believe that Dyn was DDoSed by the Mirai botnet,
>which propagates by exploiting devices configured with default credentials.
>This has nothing to do with outdated firmwares.
The problem is that you cannot realistically update those
> This started with a need for somewhat accurate system time for
> certificate validation, right? I have to deal with stuff lacking
> a RTC battery. I save system time every now and then in flash.
> During startup, clock jumps forward to RTC when warm start occurs
> (main power was not
>> So the device should have the vendor's long term TLS certicate. With possibl
>y
>> an option for the user to disable this kind of security if the device is
>> not actually connected to the internet.
>
>No, during disaster recovery the last thing you need is for ordinary people
>to be faced with
>> I.e., a router on wifi announces wifi and when a router that is on wired
>> receives an announcement from a router on wifi it knows that there
>> a bridge somewhere.
>
>Not a bad idea, but I'm a little hesitant to implement that, since it
>would require defining a taxonomy of interface types at
In your letter dated Wed, 16 Dec 2015 18:01:43 +0100 you wrote:
> 1. use the wireless type by default (as with -w), people who have
>lossless wired links will need to configure them manually; this is bad
>for Homenet, which is expected to use wired links extensively, but
>perhaps it
In your letter dated Wed, 26 Aug 2015 15:07:50 +0200 you wrote:
On Wed, Aug 26, 2015 at 2:31 PM, Juliusz Chroboczek
j...@pps.univ-paris-diderot.fr wrote:
What I'm saying is that neither DHCPv4 nor IPv6 RA are designed to deal
with prefixes that last less than a few hours. See for example RFC
In your letter dated Wed, 15 Oct 2014 16:58:43 +0200 you wrote:
Please understand that there are way more non-geeks out there that have
no interest in computers except use them than there are geeks who care
about IP addressing. *Our* job is to make it work for *them*, without
forcing our world
In your letter dated Tue, 14 Oct 2014 16:59:30 +0200 you wrote:
Because this is the only way that application developers will learn to
handle it.
I'm happy my ISP doesn't do that. I would probably just use a tunnel instead.
One of the advantages of IPv6 is that it is way easier to run publicly
In your letter dated Fri, 18 Apr 2014 09:57:21 -0430 you wrote:
You are absolutely right, thanks.
But anyway the scenario I mentioned above can also exists (and for good
or bad eventually will happen).. I just wanted to express my position
about the option NO-IPv4 in DHCPv4
I'd say that if
In your letter dated Thu, 17 Apr 2014 22:16:19 -0430 you wrote:
I like the idea of having the No-IPv4 option for DHCPv6. I don't like
the idea of having this option in a v4 world; mainly because in mix
networks where you might have some folks which only speak IPv4, imagine
a case where this
In your letter dated Wed, 16 Apr 2014 09:07:46 -0400 you wrote:
Philip Homburg pch-homene...@u-1.phicoh.com wrote:
Does that include all edge cases and the user interface?
I.e. DHCPv4 has configured an address and by mistake a RA orders IPv4
to be
shutdown. Do you just
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
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
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
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
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
24 matches
Mail list logo
