Add NetworkID field to transactions to help prevent replay attacks on and from side-chains #4370

RichardAH · 2022-12-19T16:30:18Z

High Level Overview of Change

Help to prevent replay attacks by allowing side-chains to require their users specify an accurate NetworkID field in every transaction to that chain.

This change introduces a new field:

CONSTRUCT_TYPED_SFIELD(sfNetworkID, "NetworkID", UINT32, 1);

And three new local error codes:

telNETWORK_ID_MAKES_TX_NON_CANONICAL
telREQUIRES_NETWORK_ID
telWRONG_NETWORK.

To preserve legacy behaviour (and avoid the need for an amendment) all chains with a network ID less than 1025 retain the existing behaviour. This includes main, testnet, devnet and hooks-testnet. If sfNetworkID is present in any txn submitted to any of the nodes on this chain then a telNETWORK_ID_MAKES_TX_NON_CANONICAL is returned.

All other chains now require their users to include an appropriate sfNetworkID in every transaction to that chain.

Local error codes were chosen because a transaction is not necessarily malformed if it is submitted to a node running on the incorrect chain. This is a local error specific to that node and could be corrected by switching to a different node or by changing the network_id on that node.

Test Plan

A new unit test suite has been added:

# ./rippled -u ripple.app.NetworkID
ripple.app.NetworkID Require txn NetworkID to be specified (or not) depending on the network ID of the node
501ms, 1 suite, 1 case, 23 tests total, 0 failures

Config unit test was also updated to include some network_id tests:

# ./rippled -u ripple.core.Config
ripple.core.Config legacy
ripple.core.Config database_path
Loading: "testSetup12/rippled.cfg"
Loading: "testSetup12/rippled.cfg"
Loading: "testSetup13/rippled.cfg"
Loading: "testSetup13/rippled.cfg"
ripple.core.Config validator keys
ripple.core.Config validators_file
ripple.core.Config amendment
ripple.core.Config overlay: unknown time
ripple.core.Config overlay: diverged time
ripple.core.Config network id
101ms, 1 suite, 8 cases, 260 tests total, 0 failure

All tests:

Longest suite times:
   42.0s ripple.tx.Offer
   35.0s ripple.app.ValidatorSite
   21.7s ripple.rpc.NodeToShardRPC
   20.6s ripple.tx.NFToken
   17.3s ripple.tx.NFTokenBurn
   13.9s ripple.app.Flow
   13.7s ripple.app.ShardArchiveHandler
   13.0s ripple.app.TheoreticalQuality
    8.3s ripple.app.LedgerReplayer
    7.9s ripple.tx.NFTokenDir
337.1s, 205 suites, 1529 cases, 532189 tests total, 0 failures

…rk id > 1024

intelliot · 2022-12-19T22:39:37Z

This is worth considering; however, I believe the recommendation is to use different accounts/keys on side-chains. The X-address format recommends using the X prefix for Mainnet and T for any test/development network. Additional prefixes could be defined for well-known sidechains; there could also be a prefix for side-chains in general.

RichardAH · 2022-12-19T22:55:50Z

This is worth considering; however, I believe the recommendation is to use different accounts/keys on side-chains. The X-address format recommends using the X prefix for Mainnet and T for any test/development network. Additional prefixes could be defined for well-known sidechains; there could also be a prefix for side-chains in general.

This wouldn't prevent replay attacks, it's just a client side syntactic sugar over the top of existing AccountIDs and destination tags. The resulting serialized transactions are the same and can be replayed in the same way on other chains.

Realistically people will absolutely use the same keys on multiple chains. This is an exceedingly common practice on Ethereum chains. There are even legitimate use-cases for it... such as swapping from your own account on one chain to your own account on another over a bridge without attracting a lot of unwanted/unnecessary AML legislation.

intelliot · 2022-12-19T23:02:01Z

Yes, you are correct. It is an issue if people use the same keys on multiple chains. It may be common practice, but I'm loathe to recommend it, partly because that does open up the risk of replay attacks.

Anyway, I'm fine with requiring NetworkID on new chains (as you said - Mainnet would remain unchanged). Let's get community feedback and get this reviewed.

RichardAH · 2022-12-20T07:24:36Z

Ultimately the code doesn’t affect mainnet at all (and thus doesn’t require an amendment). It’s here to automatically apply to future side chains (which I assume there will be quite a few of given the resources going into XChain amendment).

If the PR is rejected we should still ensure UINT32 field code 1 is reserved for NetworkID. As long as everyone agrees on that then dealing with multiple chains in the future will be a lot easier.

intelliot · 2022-12-20T18:24:30Z

Agreed - that's why I didn't put the Amendment label on this

mDuo13

Good change. Just curious, where did you get the 1024 cutoff? Personally I think I'd rather make it so that every non-Mainnet network requires a NetworkID, but I guess it would be disruptive to reset all the test networks just for this.

src/ripple/app/tx/impl/Transactor.cpp

mDuo13 · 2022-12-21T01:33:13Z

src/ripple/core/impl/Config.cpp

+    if (getSingleSection(secConfig, SECTION_NETWORK_ID, strTemp, j_))
+    {
+        if (strTemp == "main")
+            NETWORK_ID = 0;
+        else if (strTemp == "testnet")
+            NETWORK_ID = 1;
+        else if (strTemp == "devnet")
+            NETWORK_ID = 2;
+        else
+            NETWORK_ID = beast::lexicalCastThrow<uint32_t>(strTemp);
+    }


I noticed this section is similar to the OverlayImpl.cpp version; is that something that can be updated to be consistent or shared in some way so this switch doesn't have to be in multiple places?

I also saw this but didn't want to touch OverlayImpl. Feel free to suggest an additional commit with appropriate tests to remove this redundant code.

RichardAH · 2022-12-21T11:45:21Z

Good change. Just curious, where did you get the 1024 cutoff? Personally I think I'd rather make it so that every non-Mainnet network requires a NetworkID, but I guess it would be disruptive to reset all the test networks just for this.

It comes from the restriction on port numbers in Linux. We feel that new networks should pick a peering port that is = to their network ID, and this should always be > 1024. :)

Co-authored-by: Rome Reginelli <mduo13@gmail.com>

src/ripple/app/tx/impl/Transactor.cpp

src/test/app/NetworkID_test.cpp

SFsourDoh · 2022-12-22T01:49:54Z

should this be "help prevent replay attacks" since network IDs might not be unique?

a-noni-mousse · 2022-12-23T06:12:08Z

src/ripple/protocol/impl/SField.cpp

@@ -104,6 +104,7 @@ CONSTRUCT_TYPED_SFIELD(sfHookExecutionIndex,    "HookExecutionIndex",   UINT16,
 CONSTRUCT_TYPED_SFIELD(sfHookApiVersion,        "HookApiVersion",       UINT16,    20);

 // 32-bit integers (common)
+CONSTRUCT_TYPED_SFIELD(sfNetworkID,             "NetworkID",            UINT32,     1);


I would not resue the unused value unless you are confidente that its not used elsewhere. Also why use the ''common'' value? To save a one byte in the encoding version?

I’ve never seen UINT32 field code 1 used anywhere. Not even in old old ledgers. Maybe someone can shed light on why it was free?
It seems appropriate to use it for an important task such as preventing replay attacks.

intelliot · 2023-03-21T15:03:55Z

Requires at least 2 full code reviews from maintainers or well-known C++ engineers

gregtatcam

LGTM 👍

intelliot · 2023-03-29T05:46:21Z

Suggested commit message:

Prevent replay attacks with NetworkID field: (#4370)

Add a `NetworkID` field to help prevent replay attacks on and from
side-chains.

The new field must be used when the server is using a network id > 1024.

To preserve legacy behavior, all chains with a network ID less than 1025
retain the existing behavior. This includes Mainnet, Testnet, Devnet,
and hooks-testnet. If `sfNetworkID` is present in any transaction
submitted to any of the nodes on one of these chains, then
`telNETWORK_ID_MAKES_TX_NON_CANONICAL` is returned.

Since chains with a network ID less than 1025, including Mainnet, retain
the existing behavior, there is no need for an amendment.

The `NetworkID` helps to prevent replay attacks because users specify a
`NetworkID` field in every transaction for that chain.

This change introduces a new UINT32 field, `sfNetworkID` ("NetworkID").
There are also three new local error codes for transaction results:

- `telNETWORK_ID_MAKES_TX_NON_CANONICAL`
- `telREQUIRES_NETWORK_ID`
- `telWRONG_NETWORK`

To learn about the other transaction result codes, see
https://xrpl.org/transaction-results.html.

Local error codes were chosen because a transaction is not necessarily
malformed if it is submitted to a node running on the incorrect chain.
This is a local error specific to that node and could be corrected by
switching to a different node or by changing the `network_id` on that
node. See
https://xrpl.org/connect-your-rippled-to-the-xrp-test-net.html.

In addition to using `NetworkID`, it is still generally recommended to
use different accounts and keys on side-chains. However, people will
undoubtedly use the same keys on multiple chains; for example, this is
common practice on other blockchain networks. There are also some
legitimate use cases for this.

A `app.NetworkID` test suite has been added, and `core.Config` was
updated to include some network_id tests.

pwang200

I have a couple minor comments, but looks good!

pwang200 · 2023-03-29T16:53:24Z

src/test/jtx/impl/Env.cpp

@@ -163,7 +163,10 @@ Env::lookup(AccountID const& id) const
 {
    auto const iter = map_.find(id);
    if (iter == map_.end())
+    {
+        std::cout << "Unknown account: " << id << "\n";


Please consider to remove.

pwang200 · 2023-03-29T16:55:41Z

src/test/core/Config_test.cpp

+
+        BEAST_EXPECT(error == "");
+        BEAST_EXPECT(c.NETWORK_ID == 10000);
+    }


Please consider adding a negative case, e.g.
[network_id]
abcd

intelliot · 2023-04-11T04:41:37Z

explanation:

@pwang200 approved the PR. The suggestions could be incorporated (by @pwang200) in a commit (to be cherry picked); or if this PR has been merged, they can be suggested in a new PR.

@RichardAH confirmed this is good to go as-is.

will-yjn · 2023-06-21T02:21:22Z

For mainnet/testnet/devnet, do we have to upgrade js sdk or add networkId when we construct the transaction? Is the new networkID mechanism already on testnet/devnet so we could test?

intelliot · 2023-06-22T21:58:28Z

This change does not affect mainnet/testnet/devnet.

To preserve legacy behaviour (and avoid the need for an amendment) all chains with a network ID less than 1025 retain the existing behaviour. This includes main, testnet, devnet and hooks-testnet.

The NetworkID field must not be set in transactions on these networks.

Only sidechains and test networks with IDs of 1025 or higher need to have the NetworkID set.

The Network ID logic should not be applied to pseudo-transactions. This allows amendments to enable on a network with an ID > 1024. Context: - NetworkID: #4370 - Pseudo-transactions: https://xrpl.org/pseudo-transaction-types.html Fix #4736 --------- Co-authored-by: RichardAH <richard.holland@starstone.co.nz>

The Network ID logic should not be applied to pseudo-transactions. This allows amendments to enable on a network with an ID > 1024. Context: - NetworkID: XRPLF#4370 - Pseudo-transactions: https://xrpl.org/pseudo-transaction-types.html Fix XRPLF#4736 --------- Co-authored-by: RichardAH <richard.holland@starstone.co.nz>

Add NetworkID field to Transaction common fields, enforced when netwo…

3af76ce

…rk id > 1024

intelliot added Request for Comments Feature Request Used to indicate requests to add new features Testable Will Need Documentation labels Dec 19, 2022

intelliot requested review from seelabs, ximinez, aanchal4, pwang200, nbougalis, mvadari and oleks-rip December 19, 2022 23:03

mDuo13 approved these changes Dec 21, 2022

View reviewed changes

Update src/ripple/app/tx/impl/Transactor.cpp

437ad33

Co-authored-by: Rome Reginelli <mduo13@gmail.com>

intelliot added Medium Priority and removed Request for Comments labels Dec 21, 2022

oleks-rip reviewed Dec 21, 2022

View reviewed changes

src/ripple/app/tx/impl/Transactor.cpp Outdated Show resolved Hide resolved

oleks-rip reviewed Dec 22, 2022

View reviewed changes

src/test/app/NetworkID_test.cpp Show resolved Hide resolved

[FOLD] add const, missing include

368589c

RichardAH changed the title ~~Add NetworkID field to transactions to prevent replay attacks on and from side-chains~~ Add NetworkID field to transactions to help prevent replay attacks on and from side-chains Dec 22, 2022

a-noni-mousse approved these changes Dec 23, 2022

View reviewed changes

intelliot requested a review from JoelKatz January 10, 2023 21:26

intelliot removed the Medium Priority label Feb 8, 2023

This was referenced Feb 23, 2023

feature NetworkID XRPLF/xrpl.js#2216

Merged

feature NetworkID XRPLF/xrpl-py#520

Merged

intelliot requested a review from gregtatcam March 21, 2023 15:02

gregtatcam approved these changes Mar 21, 2023

View reviewed changes

intelliot requested a review from oleks-rip March 23, 2023 17:21

intelliot assigned pwang200 and oleks-rip Mar 23, 2023

pwang200 approved these changes Mar 29, 2023

View reviewed changes

intelliot assigned RichardAH Mar 30, 2023

intelliot removed request for JoelKatz, seelabs, aanchal4, ximinez, mvadari and oleks-rip April 11, 2023 04:41

intelliot unassigned pwang200, RichardAH and oleks-rip Apr 11, 2023

intelliot merged commit 4f95b9d into XRPLF:develop Apr 12, 2023

sappenin mentioned this pull request Jun 26, 2023

Add network_id to ServerInfo respones XRPLF/xrpl4j#427

Closed

intelliot mentioned this pull request Jun 26, 2023

Document network_id (server_info) XRPLF/xrpl-dev-portal#1977

Open

intelliot added a commit to intelliot/rippled that referenced this pull request Jul 14, 2023

API-CHANGELOG: NetworkID (XRPLF#4370)

807a3c7

intelliot mentioned this pull request Oct 11, 2023

Amendments not enabled on networks with network_id greater than 1024 (Version: 2.0.0-b1) #4736

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add NetworkID field to transactions to help prevent replay attacks on and from side-chains #4370

Add NetworkID field to transactions to help prevent replay attacks on and from side-chains #4370

RichardAH commented Dec 19, 2022 •

edited

Loading

intelliot commented Dec 19, 2022

RichardAH commented Dec 19, 2022

intelliot commented Dec 19, 2022

RichardAH commented Dec 20, 2022

intelliot commented Dec 20, 2022

mDuo13 left a comment

mDuo13 Dec 21, 2022

RichardAH Dec 21, 2022

RichardAH commented Dec 21, 2022

SFsourDoh commented Dec 22, 2022

a-noni-mousse Dec 23, 2022

RichardAH Dec 23, 2022

intelliot commented Mar 21, 2023

gregtatcam left a comment

intelliot commented Mar 29, 2023

pwang200 left a comment

pwang200 Mar 29, 2023

SirJosh1987 Apr 12, 2023

pwang200 Mar 29, 2023

intelliot commented Apr 11, 2023

will-yjn commented Jun 21, 2023 •

edited

Loading

intelliot commented Jun 22, 2023

Add NetworkID field to transactions to help prevent replay attacks on and from side-chains #4370

Add NetworkID field to transactions to help prevent replay attacks on and from side-chains #4370

Conversation

RichardAH commented Dec 19, 2022 • edited Loading

High Level Overview of Change

Test Plan

intelliot commented Dec 19, 2022

RichardAH commented Dec 19, 2022

intelliot commented Dec 19, 2022

RichardAH commented Dec 20, 2022

intelliot commented Dec 20, 2022

mDuo13 left a comment

Choose a reason for hiding this comment

mDuo13 Dec 21, 2022

Choose a reason for hiding this comment

RichardAH Dec 21, 2022

Choose a reason for hiding this comment

RichardAH commented Dec 21, 2022

SFsourDoh commented Dec 22, 2022

a-noni-mousse Dec 23, 2022

Choose a reason for hiding this comment

RichardAH Dec 23, 2022

Choose a reason for hiding this comment

intelliot commented Mar 21, 2023

gregtatcam left a comment

Choose a reason for hiding this comment

intelliot commented Mar 29, 2023

pwang200 left a comment

Choose a reason for hiding this comment

pwang200 Mar 29, 2023

Choose a reason for hiding this comment

SirJosh1987 Apr 12, 2023

Choose a reason for hiding this comment

pwang200 Mar 29, 2023

Choose a reason for hiding this comment

intelliot commented Apr 11, 2023

will-yjn commented Jun 21, 2023 • edited Loading

intelliot commented Jun 22, 2023

RichardAH commented Dec 19, 2022 •

edited

Loading

will-yjn commented Jun 21, 2023 •

edited

Loading