public inbox for netdev@vger.kernel.org
 help / color / mirror / Atom feed
From: Eric Dumazet <eric.dumazet@gmail.com>
To: Stefani Seibold <stefani@seibold.net>
Cc: Jesper Juhl <jj@chaosbits.net>,
	linux-kernel@vger.kernel.org, akpm@linux-foundation.org,
	davem@davemloft.net, netdev@vger.kernel.org,
	shemminger@vyatta.com, daniel.baluta@gmail.com,
	jochen@jochen.org
Subject: Re: [PATCH] new UDPCP Communication Protocol
Date: Mon, 03 Jan 2011 10:27:47 +0100	[thread overview]
Message-ID: <1294046867.2892.101.camel@edumazet-laptop> (raw)
In-Reply-To: <1294045732.19666.6.camel@wall-e>

Le lundi 03 janvier 2011 à 10:08 +0100, Stefani Seibold a écrit :

> This will not work for two reasons:
> 
> - First there is no way to detect a dead connection. A connection can
> stay for a very long time without data transfer.
> 
> - Second it will not save against a attack where all communication slots
> will be eaten by an attacker and then new valid connections will be not
> handled.
> 
> The only thing what is possible to make an ioctl call which allows the
> user land client to cancel connections. 
> 
> But this will be in my opinion dead code, because white lists of trusted
> address must be fostered and this will make the upgrading of a
> infrastructure to complicate.
> 
> 

Yep, and as UDP messages can easily spoofed, this means you need more
than a list of trusted addresses. You also need to encapsulate the thing
in an secured layer.

Stefani, your implementation has very litle chance being added in
standard kernel, because it is not correctly layered, or documented.

Copying hundred (thousand ?) of lines from existing code only shows
there is a design error in your proposal. It means every time we have to
make a change in this code, we'll have to do it twice.

SUNRPC uses UDP/TCP sockets, and use callbacks to existing UDP/TCP code,
maybe you should take a look to implement an UDPCP stack in kernel.

For instance, a pure socket API seems not the correct choice for UDPCP,
since a transmit should give a report to user, of frame being
delivered/aknowledged or not to/by the remote side ?

With send(), this means you have only one message in transit, no
asynchronous handling.

At least you forgot to document the API, and restrictions.

  reply	other threads:[~2011-01-03  9:27 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-01-02 22:39 [PATCH] new UDPCP Communication Protocol stefani
2011-01-02 22:49 ` Eric Dumazet
2011-01-02 22:55   ` Stefani Seibold
2011-01-02 23:04     ` Jesper Juhl
2011-01-03  9:08       ` Stefani Seibold
2011-01-03  9:27         ` Eric Dumazet [this message]
2011-01-03  9:54           ` Stefani Seibold
2011-01-03 10:39             ` Eric Dumazet
2011-01-03 14:08               ` Stefani Seibold
  -- strict thread matches above, loose matches on Subject: below --
2011-01-11 16:48 stefani
2011-01-11 17:01 ` Eric Dumazet
2011-01-11 20:50   ` Stefani Seibold
2011-01-11 20:52     ` David Miller
2011-01-11 21:14       ` Stefani Seibold
2011-01-11 21:19         ` David Miller
2011-01-11 21:41           ` Stefani Seibold
2011-01-11 21:46             ` Eric Dumazet
2011-01-11 22:23               ` Stefani Seibold
2011-01-11 21:30         ` Eric Dumazet
2011-01-11 21:40           ` Stefani Seibold
2011-01-11 21:06     ` Eric Dumazet
2011-01-03 14:34 stefani
2011-01-02 15:31 stefani
2011-01-02 16:34 ` Eric Dumazet
2011-01-02 19:48 ` Daniel Baluta
2011-01-02 21:33   ` Stefani Seibold
2011-01-02 21:40     ` Jesper Juhl
2011-01-02 19:55 ` Jesper Juhl
2011-01-02 21:46   ` Stefani Seibold
2011-01-02 22:04     ` Jesper Juhl
2011-01-02 22:21       ` Stefani Seibold
2011-01-02 20:16 ` Rémi Denis-Courmont
2011-01-02 21:37   ` Stefani Seibold
2011-01-02 21:55 ` Eric Dumazet
2011-01-02 22:16   ` Stefani Seibold
2011-01-02 22:31     ` Eric Dumazet
2011-01-01 21:44 stefani
2011-01-01 22:23 ` Eric Dumazet
2011-01-02 11:17   ` Stefani Seibold
2011-01-02 11:33     ` Eric Dumazet
2011-01-02 11:57       ` Stefani Seibold

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1294046867.2892.101.camel@edumazet-laptop \
    --to=eric.dumazet@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=daniel.baluta@gmail.com \
    --cc=davem@davemloft.net \
    --cc=jj@chaosbits.net \
    --cc=jochen@jochen.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=shemminger@vyatta.com \
    --cc=stefani@seibold.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox