Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1537988 > unrolled thread

Misalignment, MIPS, and ip_hdr(skb)->version

Back to article view | Back to linux.kernel

Contents

  Misalignment, MIPS, and ip_hdr(skb)->version "Jason A. Donenfeld" <Jason@zx2c4.com> - 2016-12-07 19:40 +0100
    Re: Misalignment, MIPS, and ip_hdr(skb)->version Dave Taht <dave.taht@gmail.com> - 2016-12-07 19:50 +0100
      Re: Misalignment, MIPS, and ip_hdr(skb)->version "Jason A. Donenfeld" <Jason@zx2c4.com> - 2016-12-07 20:00 +0100
        Re: Misalignment, MIPS, and ip_hdr(skb)->version David Miller <davem@davemloft.net> - 2016-12-07 21:00 +0100
          Re: Misalignment, MIPS, and ip_hdr(skb)->version "Jason A. Donenfeld" <Jason@zx2c4.com> - 2016-12-08 01:40 +0100
            Re: Misalignment, MIPS, and ip_hdr(skb)->version David Miller <davem@davemloft.net> - 2016-12-08 01:40 +0100
              Re: Misalignment, MIPS, and ip_hdr(skb)->version "Jason A. Donenfeld" <Jason@zx2c4.com> - 2016-12-08 23:30 +0100
                Re: Misalignment, MIPS, and ip_hdr(skb)->version David Miller <davem@davemloft.net> - 2016-12-09 00:20 +0100
                Re: Misalignment, MIPS, and ip_hdr(skb)->version Willy Tarreau <w@1wt.eu> - 2016-12-11 09:10 +0100
                  Re: Misalignment, MIPS, and ip_hdr(skb)->version Måns Rullgård <mans@mansr.com> - 2016-12-11 11:50 +0100
        Re: Misalignment, MIPS, and ip_hdr(skb)->version Felix Fietkau <nbd@nbd.name> - 2016-12-10 13:30 +0100
          Re: Misalignment, MIPS, and ip_hdr(skb)->version Måns Rullgård <mans@mansr.com> - 2016-12-10 14:30 +0100
            Re: Misalignment, MIPS, and ip_hdr(skb)->version Felix Fietkau <nbd@nbd.name> - 2016-12-10 21:20 +0100
              Re: Misalignment, MIPS, and ip_hdr(skb)->version Felix Fietkau <nbd@nbd.name> - 2016-12-10 21:40 +0100
              Re: Misalignment, MIPS, and ip_hdr(skb)->version Måns Rullgård <mans@mansr.com> - 2016-12-10 21:40 +0100
            RE: Misalignment, MIPS, and ip_hdr(skb)->version David Laight <David.Laight@ACULAB.COM> - 2016-12-12 17:20 +0100
              Re: Misalignment, MIPS, and ip_hdr(skb)->version Måns Rullgård <mans@mansr.com> - 2016-12-12 17:40 +0100
      Re: Misalignment, MIPS, and ip_hdr(skb)->version David Miller <davem@davemloft.net> - 2016-12-07 20:00 +0100
    Re: Misalignment, MIPS, and ip_hdr(skb)->version Hannes Frederic Sowa <hannes@stressinduktion.org> - 2016-12-08 01:40 +0100
      Re: Misalignment, MIPS, and ip_hdr(skb)->version Daniel Kahn Gillmor <dkg@fifthhorseman.net> - 2016-12-08 06:10 +0100
        Re: Misalignment, MIPS, and ip_hdr(skb)->version Jiri Benc <jbenc@redhat.com> - 2016-12-09 12:30 +0100
        Re: Misalignment, MIPS, and ip_hdr(skb)->version Dan Lüdtke <mail@danrl.com> - 2016-12-10 23:30 +0100
          Re: Misalignment, MIPS, and ip_hdr(skb)->version Greg KH <gregkh@linuxfoundation.org> - 2016-12-11 08:20 +0100
            Re: Misalignment, MIPS, and ip_hdr(skb)->version "Jason A. Donenfeld" <Jason@zx2c4.com> - 2016-12-11 16:00 +0100
              Re: Misalignment, MIPS, and ip_hdr(skb)->version "Jason A. Donenfeld" <Jason@zx2c4.com> - 2016-12-11 16:40 +0100
              Re: Misalignment, MIPS, and ip_hdr(skb)->version Andrew Lunn <andrew@lunn.ch> - 2016-12-11 16:40 +0100
              Re: Misalignment, MIPS, and ip_hdr(skb)->version Willy Tarreau <w@1wt.eu> - 2016-12-11 17:50 +0100

Page 2 of 2 — ← Prev page 1 [2]

#1539290

On Wed, 07 Dec 2016 23:34:21 -0500, Daniel Kahn Gillmor wrote:
> fwiw, i'm not convinced that "most protocols of the IETF follow this
> mantra".  we've had multiple discussions in different protocol groups
> about shaving or bloating by a few bytes here or there in different
> protocols, and i don't think anyone has brought up memory alignment as
> an argument in any of the discussions i've followed.

Which is sad. One would expect that this would be well understood for
decades already.

 Jiri

[toc] | [prev] | [next] | [standalone]

#1539920

> On 8 Dec 2016, at 05:34, Daniel Kahn Gillmor <dkg@fifthhorseman.net> wrote:
> 
> On Wed 2016-12-07 19:30:34 -0500, Hannes Frederic Sowa wrote:
>> Your custom protocol should be designed in a way you get an aligned ip
>> header. Most protocols of the IETF follow this mantra and it is always
>> possible to e.g. pad options so you end up on aligned boundaries for the
>> next header.
> 
> fwiw, i'm not convinced that "most protocols of the IETF follow this
> mantra".  we've had multiple discussions in different protocol groups
> about shaving or bloating by a few bytes here or there in different
> protocols, and i don't think anyone has brought up memory alignment as
> an argument in any of the discussions i've followed.
> 

If the trade-off is between 1 padding byte and 2 byte alignment versus 3 padding bytes and 4 byte alignment I would definitely opt for 3 padding bytes. I know how that waste feels like to a protocol designer, but I think it is worth it. Maybe the padding/reserved will be useful some day for an additional feature.

I remember alignment being discussed and taken very seriously in 6man a couple of times. Often, though, protocol designers did align without much discussion. Implementing unaligned protocols is a pain I've experienced first hand.

[toc] | [prev] | [next] | [standalone]

#1539986

On Sat, Dec 10, 2016 at 11:18:14PM +0100, Dan Lüdtke wrote:
> 
> > On 8 Dec 2016, at 05:34, Daniel Kahn Gillmor <dkg@fifthhorseman.net> wrote:
> > 
> > On Wed 2016-12-07 19:30:34 -0500, Hannes Frederic Sowa wrote:
> >> Your custom protocol should be designed in a way you get an aligned ip
> >> header. Most protocols of the IETF follow this mantra and it is always
> >> possible to e.g. pad options so you end up on aligned boundaries for the
> >> next header.
> > 
> > fwiw, i'm not convinced that "most protocols of the IETF follow this
> > mantra".  we've had multiple discussions in different protocol groups
> > about shaving or bloating by a few bytes here or there in different
> > protocols, and i don't think anyone has brought up memory alignment as
> > an argument in any of the discussions i've followed.
> > 
> 
> If the trade-off is between 1 padding byte and 2 byte alignment versus
> 3 padding bytes and 4 byte alignment I would definitely opt for 3
> padding bytes. I know how that waste feels like to a protocol
> designer, but I think it is worth it. Maybe the padding/reserved will
> be useful some day for an additional feature.

Note, if you do do this (hint, I think it is a good idea), require that
these reserved/pad fields always set to 0 for now, so that no one puts
garbage in them and then if you later want to use them, it will be a
mess.

thanks,

greg k-h

[toc] | [prev] | [next] | [standalone]

#1540029

Hey guys,

Thanks for the extremely detailed answers. The main take-away from
this is that passing unaligned packets to the networking stack kills
kittens. So now it's a question of mitigation. I have three options:

1. Copy the plaintext to three bytes before the start of the cipher
text, overwriting parts of the header that aren't actually required.
Pros: no changes required, MTU stays small.
Cons: scatterwalk's fast paths aren't hit, which means two page table
mappings are taken instead of one. I have no idea if this actually
matters or will slow down anything relavent.

2. Add 3 bytes to the plaintext header, set to zero, marked for future use.
Pros: satisfies IETF mantras and makes unaligned in-place decryption
straightforward.
Cons: lowers MTU, additional unauthenticated cleartext bits in the
header are of limited utility in protocol.

3. Add 3 bytes of padding, set to zero, to the encrypted section just
before the IP header, marked for future use.
Pros: satisfies IETF mantras, can use those extra bits in the future
for interesting protocol extensions for authenticated peers.
Cons: lowers MTU, marginally more difficult to implement but still
probably just one or two lines of code.

Of these, I'm leaning toward (3).

Anyway, thanks a lot for the input. "Doing nothing" is no longer under
serious consideration, thanks to your messages.

Thanks,
Jason

[toc] | [prev] | [next] | [standalone]

#1540033

On Sun, Dec 11, 2016 at 4:30 PM, Andrew Lunn <andrew@lunn.ch> wrote:
> I'm not a crypto expert, but does this not give you a helping hand in
> breaking the crypto? You know the plain text value of these bytes, and
> where they are in the encrypted text.

You also know with some probability that there's going to be an IP
header and a TCP header, each with predictable fields. Maybe you're
reasonably certain there's an HTTP header in there too. Gasp! But fear
not...

Symmetric ciphers are generally not considered secure if they fall to
what's called a "known plaintext attack". Fortunately, modern ciphers
like AES and ChaCha20 and most others that you're aware of are
generally believed to be secure against KPA.

[toc] | [prev] | [next] | [standalone]

#1540040

> 3. Add 3 bytes of padding, set to zero, to the encrypted section just
> before the IP header, marked for future use.
> Pros: satisfies IETF mantras, can use those extra bits in the future
> for interesting protocol extensions for authenticated peers.
> Cons: lowers MTU, marginally more difficult to implement but still
> probably just one or two lines of code.

I'm not a crypto expert, but does this not give you a helping hand in
breaking the crypto? You know the plain text value of these bytes, and
where they are in the encrypted text.

      Andrew

[toc] | [prev] | [next] | [standalone]

#1540041

On Sun, Dec 11, 2016 at 03:50:31PM +0100, Jason A. Donenfeld wrote:
> 3. Add 3 bytes of padding, set to zero, to the encrypted section just
> before the IP header, marked for future use.
> Pros: satisfies IETF mantras, can use those extra bits in the future
> for interesting protocol extensions for authenticated peers.
> Cons: lowers MTU, marginally more difficult to implement but still
> probably just one or two lines of code.
> 
> Of these, I'm leaning toward (3).

Or 4) add one byte to the cleartext header for future use (mostly flags
maybe) and 2 bytes of padding to the encrypted header. This way you get
the following benefits :
  1) your encrypted text is at least 16-bit aligned, maybe it matters
     in your checksum computations on during decryption
  2) your MTU remains even, this is better for both ends
  3) you're free to add some bits either to the encrypted or the clear
     parts.

Just a suggestion :-)

Willy

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | linux.kernel

csiph-web