On 7/03/2014, at 2:15 PM, Richard Procter wrote:
I've some ideas about solutions [for modifying checksums more cleanly] but
will
leave those for another email.
Shifting this old thread to tech@: I've posted a patch that re-instates
the pf algorithm of OpenBSD 5.4 for preserving payload
On 27/02/2014, at 11:04 AM, Theo de Raadt wrote:
There was a method of converting an in-bound checksum, due to NAT
conversion, into a new out-bound checksum. A process is required,
it's how NAT works.
A new method of version is being used. It is mathematically equivelant
to the old
On 24/02/2014, at 9:33 PM, Henning Brauer wrote:
* Richard Procter richard.n.proc...@gmail.com [2014-01-25 20:41]:
On 22/01/2014, at 7:19 PM, Henning Brauer wrote:
* Richard Procter richard.n.proc...@gmail.com [2014-01-22 06:44]:
This fundamentally weakens its usefulness, though: a correct
On 24/02/2014, at 9:33 PM, Henning Brauer wrote:
* Richard Procter richard.n.proc...@gmail.com [2014-01-25 20:41]:
On 22/01/2014, at 7:19 PM, Henning Brauer wrote:
* Richard Procter richard.n.proc...@gmail.com [2014-01-22 06:44]:
This fundamentally weakens its usefulness, though: a
Again, it's not just me saying it: ...checksums are used by
higher layers to ensure that data was not corrupted in
intermediate routers or by the sending or receiving host.
The fact that checksums are typically the secondary level of
protection has often led to suggestions that checksums are
On 27/02/2014, at 11:04 AM, Theo de Raadt wrote:
I believe you are posting cast aspersions on the pf efforts.
Theo,
I'll insist then that I think pf is a superior piece of code
which I benefit from every day, and that Henning's efforts
to simplify it are so very welcome in a world addicted to
* Richard Procter richard.n.proc...@gmail.com [2014-01-25 20:41]:
On 22/01/2014, at 7:19 PM, Henning Brauer wrote:
* Richard Procter richard.n.proc...@gmail.com [2014-01-22 06:44]:
This fundamentally weakens its usefulness, though: a correct
checksum now implies only that the payload likely
* Geoff Steckel g...@oat.com [2014-01-28 03:20]:
It would be good if when data protected by a checksum is modified,
the current checksum is validated and some appropriate?
guess what: that is exactly what happens.
--
Henning Brauer, h...@bsws.de, henn...@openbsd.org
BS Web Services GmbH,
On 28/01/2014, at 4:19 AM, Simon Perreault wrote:
Le 2014-01-25 14:40, Richard Procter a écrit :
I'm not saying the calculation is bad. I'm saying it's being
calculated from the wrong copy of the data and by the wrong
device. And it's not just me saying it: I'm quoting the guys
who designed
Le 2014-01-27 21:21, Geoff Steckel a écrit :
It would be good if when data protected by a checksum is modified,
the current checksum is validated and some appropriate? action is done
(drop? produce invalid new checksum?) when proceeding.
This is exactly what's being done. Don't you listen
Le 2014-01-28 03:39, Richard Procter a écrit :
In order to hide payload corruption the update code would
have to modify the checksum to exactly account for it. But
that would have to happen by accident, as it never considers
the payload. It's not impossible, but, on the other hand,
checksum
On 2014-01-28, Simon Perreault sperrea...@openbsd.org wrote:
Le 2014-01-28 03:39, Richard Procter a écrit :
In order to hide payload corruption the update code would
have to modify the checksum to exactly account for it. But
that would have to happen by accident, as it never considers
the
Em 28-01-2014 15:45, Stuart Henderson escreveu:
On 2014-01-28, Simon Perreault sperrea...@openbsd.org wrote:
Le 2014-01-28 03:39, Richard Procter a écrit :
In order to hide payload corruption the update code would
have to modify the checksum to exactly account for it. But
that would have to
Le 2014-01-28 12:45, Stuart Henderson a écrit :
This analysis is bullshit. You need to take into account the fact that
checksums are verified before regenerating them. That is, you need to
compare a) verifying + regenerating vs b) updating. If there's an
undetectable error, you're going to
On Mon, Jan 27, 2014 at 8:19 AM, Simon Perreault
simon.perrea...@viagenie.ca wrote:
Le 2014-01-25 14:40, Richard Procter a écrit :
I'm not saying the calculation is bad. I'm saying it's being
calculated from the wrong copy of the data and by the wrong
device. And it's not just me saying
Le 2014-01-25 14:40, Richard Procter a écrit :
I'm not saying the calculation is bad. I'm saying it's being
calculated from the wrong copy of the data and by the wrong
device. And it's not just me saying it: I'm quoting the guys
who designed TCP.
Those guys didn't envision NAT.
If you want
Em 27-01-2014 14:30, Nick Bender escreveu:
On Mon, Jan 27, 2014 at 8:19 AM, Simon Perreault
simon.perrea...@viagenie.ca wrote:
Le 2014-01-25 14:40, Richard Procter a écrit :
I'm not saying the calculation is bad. I'm saying it's being
calculated from the wrong copy of the data and by the
FWIW, you don't have to out in the sticks (the backwoods?) to have
a network problem:
http://mina.naguib.ca/blog/2012/10/22/the-little-ssh-that-sometimes-couldnt.html
However, as I understand it, in this case the TCP checksumming worked
and protected the application from the corrupted data.
Em 27-01-2014 19:05, Why 42? The lists account. escreveu:
FWIW, you don't have to out in the sticks (the backwoods?) to have
a network problem:
http://mina.naguib.ca/blog/2012/10/22/the-little-ssh-that-sometimes-couldnt.html
However, as I understand it, in this case the TCP
On 01/27/2014 08:07 PM, Giancarlo Razzolini wrote:
Em 27-01-2014 19:05, Why 42? The lists account. escreveu:
FWIW, you don't have to out in the sticks (the backwoods?) to have
a network problem:
http://mina.naguib.ca/blog/2012/10/22/the-little-ssh-that-sometimes-couldnt.html
However,
On 22/01/2014, at 7:19 PM, Henning Brauer wrote:
* Richard Procter richard.n.proc...@gmail.com [2014-01-22 06:44]:
This fundamentally weakens its usefulness, though: a correct
checksum now implies only that the payload likely matches
what the last NAT router happened to have in its memory
)
Subject: Re: NAT reliability in light of recent checksum changes
From: Richard Procter richard.n.proc...@gmail.com
In-Reply-To: 20140122061907.gk15...@quigon.bsws.de
Date: Sun, 26 Jan 2014 08:40:44 +1300
Content-Transfer-Encoding: 8bit
References: 8d493091-c15d-46a2-8004-32dd59395...@gmail.com
Henning Brauer lists-open...@bsws.de wrote:
This fundamentally weakens its usefulness, though: a correct
checksum now implies only that the payload likely matches
what the last NAT router happened to have in its memory,
whereas the receiver wants to know whether what it got is
what was
On 2014-01-15, Stuart Henderson s...@spacehopper.org wrote:
On 2014-01-14, Richard Procter richard.n.proc...@gmail.com wrote:
I've a question about the new checksum changes. [...]
My understanding is that checksums are now always recalculated when
a header is altered, never updated.
Is
* Richard Procter richard.n.proc...@gmail.com [2014-01-22 06:44]:
That is exactly what slides 30-33 talk about. PF now checks
the incoming packets before it rewrites the checksum, so it can
reject them if they are broken.
Right -- so NAT now replaces the existing transport checksum
with
On 2014-01-14, Richard Procter richard.n.proc...@gmail.com wrote:
Hi all,
I'm using OpenBSD 5.3 to provide an Alix-based home firewall. Thank
you all for the commitment to elegant, well-documented software which
isn't pernicious to the mental health of its users.
I've a question about the
Hi all,
I'm using OpenBSD 5.3 to provide an Alix-based home firewall. Thank
you all for the commitment to elegant, well-documented software which
isn't pernicious to the mental health of its users.
I've a question about the new checksum changes[0], being interested
in such things and having
27 matches
Mail list logo
