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 ol
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
> 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
> On 24/02/2014, at 9:33 PM, Henning Brauer wrote:
>
> > * Richard Procter [2014-01-25 20:41]:
> >> On 22/01/2014, at 7:19 PM, Henning Brauer wrote:
> >>> * Richard Procter [2014-01-22 06:44]:
> This fundamentally weakens its usefulness, though: a correct
> checksum now implies only th
On 24/02/2014, at 9:33 PM, Henning Brauer wrote:
> * Richard Procter [2014-01-25 20:41]:
>> On 22/01/2014, at 7:19 PM, Henning Brauer wrote:
>>> * Richard Procter [2014-01-22 06:44]:
This fundamentally weakens its usefulness, though: a correct
checksum now implies only that the payload
* Geoff Steckel [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, http://bsws.
* Richard Procter [2014-01-25 20:41]:
> On 22/01/2014, at 7:19 PM, Henning Brauer wrote:
> > * Richard Procter [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 happene
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 propag
Em 28-01-2014 15:45, Stuart Henderson escreveu:
> On 2014-01-28, Simon Perreault 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 ac
On 2014-01-28, Simon Perreault 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 payload. It's not
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 regen
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 w
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 d
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
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 check
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 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 dat
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 s
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 end
us-ascii
>Mime-Version: 1.0 (Apple Message framework v1085)
>Subject: Re: NAT reliability in light of recent checksum changes
>From: Richard Procter
>In-Reply-To: <20140122061907.gk15...@quigon.bsws.de>
>Date: Sun, 26 Jan 2014 08:40:44 +1300
>Content-Transfer-Encoding:
On 22/01/2014, at 7:19 PM, Henning Brauer wrote:
> * Richard Procter [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
>
> huh?
> we receive a
Henning Brauer 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 originally t
* Richard Procter [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 one newly computed fro
On 2014-01-15, Stuart Henderson wrote:
> On 2014-01-14, Richard Procter 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 that right and if so has this affect
On 2014-01-14, Richard Procter 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 new checksum changes[
26 matches
Mail list logo
