All of lore.kernel.org
 help / color / mirror / Atom feed
From: Florian Westphal <fw@strlen.de>
To: sriram.yagnaraman@est.tech
Cc: netfilter-devel@vger.kernel.org, kernel test robot <lkp@intel.com>
Subject: Re: [PATCH v2 1/2] netfilter: conntrack: introduce no_random_port proc entry
Date: Mon, 31 Oct 2022 09:38:58 +0100	[thread overview]
Message-ID: <20221031083858.GB5040@breakpoint.cc> (raw)
In-Reply-To: <20221030122541.31354-2-sriram.yagnaraman@est.tech>

sriram.yagnaraman@est.tech <sriram.yagnaraman@est.tech> wrote:
> From: Sriram Yagnaraman <sriram.yagnaraman@est.tech>
> 
> This patch introduces a new proc entry to disable source port
> randomization for SCTP connections.

Hmm.  Can you elaborate?  The sport is never randomized, unless either
1. User explicitly requested it via "random" flag passed to snat rule, or
2. the is an existing connection, using the *same* sport:saddr -> daddr:dport
   quadruple as the new request.

In 2), this new toggle prevents communication.  So I wonder why ...

> As specified in RFC9260 all transport addresses used by an SCTP endpoint
> MUST use the same port number but can use multiple IP addresses. That
> means that all paths taken within an SCTP association should have the
> same port even if they pass through different NAT/middleboxes in the
> network.

... the rfc mandates this, especially given the fact that endpoints have
0 control on middlebox behaviour.

This flag will completely prevent communication in case another
middlebox does sport randomization, so I wonder why its needed -- I see
no advantages but I see a downside.

> Disabling source port randomization provides a deterministic source port
> for the remote SCTP endpoint for all paths used in the SCTP association.
> On NAT/middlebox restarts we will always end up with the same port after
> the restart, and the SCTP endpoints involved in the SCTP association can
> remain transparent to restarts.

Can you elaborate? If we're the middlebox and we restarted, we have no
record of the "old" incarnation so there is no sport reallocation.

> Of course, there is a downside as this makes it impossible to have
> multiple SCTP endpoints behind NAT that use the same source port.

Hmm?  Not following.

1.2.3.4:12345 -> 5.6.7.8:42
1.2.3.4:12345 -> 5.6.7.8:43

... should work fine. Same for
1.2.3.4:12345 -> 5.6.7.8:42
1.2.3.4:12345 -> 5.6.7.9:42

> But, this is a lesser of a problem than losing an existing association
> altogether.

Can you elaborate?  How is an existing assocation lost?
For example, what sequence of events is needed to result in loss of
an existing association?

  reply	other threads:[~2022-10-31  8:39 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-30 12:25 [PATCH v2 0/2] netfilter: conntrack: improve SCTP multihoming sriram.yagnaraman
2022-10-30 12:25 ` [PATCH v2 1/2] netfilter: conntrack: introduce no_random_port proc entry sriram.yagnaraman
2022-10-31  8:38   ` Florian Westphal [this message]
2022-10-31 18:41     ` Sriram Yagnaraman
2022-11-02 14:00       ` Florian Westphal
2022-11-03 20:02         ` Sriram Yagnaraman
2022-11-21 11:24           ` Marcelo Ricardo Leitner
2022-10-30 12:25 ` [PATCH v2 2/2] netfilter: conntrack: add sctp DATA_SENT state sriram.yagnaraman
2022-11-02 14:02   ` Florian Westphal
2022-11-21 11:20   ` Marcelo Ricardo Leitner

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=20221031083858.GB5040@breakpoint.cc \
    --to=fw@strlen.de \
    --cc=lkp@intel.com \
    --cc=netfilter-devel@vger.kernel.org \
    --cc=sriram.yagnaraman@est.tech \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.