Re: [PATCH v2 1/2] netfilter: conntrack: introduce no_random_port proc entry

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



sriram.yagnaraman@xxxxxxxx <sriram.yagnaraman@xxxxxxxx> wrote:
> From: Sriram Yagnaraman <sriram.yagnaraman@xxxxxxxx>
> 
> 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?



[Index of Archives]     [Netfitler Users]     [Berkeley Packet Filter]     [LARTC]     [Bugtraq]     [Yosemite Forum]

  Powered by Linux