zzz.i2p

Development discussions
 
Wed, 22 Aug 2018, 05:07pm #1
zzz
Administrator
Zzz

Thread for possible replacement of SSU using Noise.

Todo: add goals, lessons learned from NTCP2.
Reference WireGuard which I believe is the only Noise-over-UDP protocol out there.
https://www.wireguard.com/protocol/

Formal proposal to follow, some day.
Optimistic timeline: Spec mid/late 2019, implementation 2020
Subject to discussion on priorities after we finish with LS2, but no end in sight yet for LS2.

Fri, 31 Aug 2018, 03:59pm #2
zzz
Administrator
Zzz

Wireguard data phase has unencrypted, unobfuscated header: message type, 3 bytes of zeros, receiver index, and counter.
Handshake also has unencrypted, unobfuscated contents.

Also, I saw an article on why IK was much better than XK because it saves half a round trip? No. IK requires one more DH, and doesn't save any round trip. Alice connects to Bob because Alice wants to send something to Bob, so it doesn't send any time at all. Unless Alice magically knows that Bob has something to send to her, and connects to Bob first.

We already looked at Wireguard when working on NTCP2, and will certainly use it as a reference for SSU2. But we can't do exactly what they do. In general, SSU is in much better shape than NTCP 1 was, because SSU has a MAC already.

Will need to start with a list of goals. What in SSU needs to be fixed/improved (besides ElG of course)?

Sat, 01 Sep 2018, 05:55pm #3
Qubes
I2P Legend

I would like to see the wireguard protocol implemented over 100 nodes (not 2 as in the video). A university can do that (CS department) in their lunch break. I would also like for hardware security (the most common name Yubi) to be optional in i2p (reseeding specifically).

Hope that it works!

Wed, 23 Sep 2020, 10:54am #4
zzz
Administrator
Zzz

Bump, starting to discuss in #ls2 meetings
notes to self follow

Wed, 23 Sep 2020, 10:55am #5
zzz
Administrator
Zzz

               SSU1                    SSU1
Msg IKey SKey Needs Replay Date Inside
0 Sess Req X X
1 SessResp X X X
2 SessConf X X
3 Rly Req X X X?
4 Rly Resp X X X?
5 RlyIntro X
6 Data X
7 PeerTest X X X?
8 Destroy X


SSU1 header
16 MAC
16 IV
1 Type
4 Date
----
37


Wireguard Noise IK cleartext header
1 type
3 unused
4 conn ID
8 n
----
16

Wed, 23 Sep 2020, 11:11am #6
zzz
Administrator
Zzz

PacketHandler state machine insanity:

lookup established PeerState based on host/port pair (RemoteHostID)
if found, AES decrypt and check MAC (session key)

if not found, lookup InboundEstablishState
if found, try decrypt
if failed decrypt, go through entire PeerState table looking for same IP and different port,
for each one, try decrypt with session key
if success, change port in peer state

if not found, lookup OutboundEstablishState
if found, try decrypt
if failed decrypt, go through entire PeerState table looking for same IP and different port,
for each one, try decrypt with session key
if success, change port in peer state

if not found, try decrypt with intro key
packets that succeed here are probably one of:
// 304 byte Session Request
// 96 byte Relay Request
// 60 byte Relay Response
// 80 byte Peer Test

if failed decrypt, go through entire PeerState table looking for same IP and different port,
for each one, try decrypt with session key
// Note that the vast majority of these are NOT corrupted packets, but
// packets for which we don't have the PeerState (i.e. SessionKey)
// Case 1: 48 byte destroy packet, we already closed
// Case 2: 369 byte session created packet, re-tx of one that failed validation
// (peer probably doesn't know his correct external port, esp. on <= 0.9.1
// Case 3:
// For peers that change ports, look for an existing session with the same IP
// If we find it, and the packet validates with its mac key, tell the transport
// to change the port, and handle the packet.
if success, change port in peer state

Wed, 23 Sep 2020, 01:50pm #7
zzz
Administrator
Zzz

Signature of 'critical data' inside Session Confirmed causes issues

Wed, 23 Sep 2020, 03:30pm #8
zzz
Administrator
Zzz

MitM/DPI protocol identification goals / threat model:

From NTCP2 goals:

"online" DPI w/o netdb knowledge cannot identify protocol quickly - or at all
"offline" DPI with netdb knowledge and more time can identify protocol

NTCP2 design:

DPI must have Bob's router hash and IV from the netdb to AES-decrypt X. Then verify it's an X25519 public key. This is essentially obfuscation for those with netdb knowledge.

SSU1 design:

DPI must have Bob's intro key from the netdb to AES-decrypt some packets (MAC and IV are in packet headers):
// 304 byte Session Request
// 96 byte Relay Request
// 60 byte Relay Response
// 80 byte Peer Test
this is sufficient to identify the protocol

NTCP2 is "harder" than SSU1, I think, because there's false positives in public key identification. With SSU1, you have a MAC so it's a sure thing, for some packets.

SSU2 design:

???

a lot of the issues in post 6 would be solved if we had an obfuscated version of a wireguard-like header

Thu, 24 Sep 2020, 02:26pm #9
zzz
Administrator
Zzz

What are the security requirements and threat model for the following two sequences:

1) Introduction: Relay request/response/hole punch followed by standard session req/resp/conf.

2) Peer Test: 7 of them

Should a full noise handshake (implying at least one extra RTT) be required beforehand? What can a MitM/DPI learn or how could it interfere?

Mon, 28 Sep 2020, 07:46pm #10
zzz
Administrator
Zzz

Notes from today's #ls2 meeting:

- things get a lot easier if it's wireguard-like in the header
- Threat model of offline DPI (that has intro key), what it can see, is important to decide

Sat, 03 Oct 2020, 11:03pm #11
zzz
Administrator
Zzz

Notes to self

SSU 1 and 2 on the same port is a goal, as with NTCP2

We can't use the length detection like we did for NTCP2, because there's 4 different packet types with intro key.

Would have to be fairly efficient both for try-ssu-1-first and try-ssu-2-first, or at least for one of those.

If obfuscated header contains checksum or MAC calculated quickly, then we could always do SSU2 first. 16 bits minimum to reduce false positives. We used CRC32 for blinded b32 ("b33"). 4 byte conn id chosen by alice should be fine and results in randomized obfuscated headers.

If we reduced max length of "n" in header we could still fit it in 16 bytes. Do we plan to do ratchet-style rekeying to keep max n to 65535?

-----

out of order, do we use ratchet-style PRNG to generate keys? We don't need tags if we put n in the header. Don't think we need tags.

Don't think we want a memory model similar to ratchet. Typ. router has 100x more SSU conns than ratchet conns.

Needs to be memory-efficient and avoid any trial DH if possible.

-------

XK with an AES header still sounds pretty good.

------

At this rate, probably early 2021 for spec, mid-to-late-2021 for rollout. ECIES for routers (prop. 152/156/157) proving much more straightforward.

------

this is slow going for the #ls2 team, definitely could use some help for those familiar with SSU, Mondays 6:30 PM IRC #ls2

Fri, 30 Jul 2021, 03:32pm #12
zzz
Administrator
Zzz

Update:

#ls2 team decided to do proposal 157 (short tunnel build messages) first. We anticipated it would be a quick effort but it took nine months. We also thought we could work on proposal 157 and SSU2 at the same time, but that didn't happen. We have not started on the SSU2 spec at all.

So the schedule at the end of the post above has slipped by about 6-9 months.

We're due for another discussion in #ls2 about what to do next, but SSU2 should be near the top. i2pd has identified SSU as the big remaining CPU hog, thanks to ElGamal.

That would put an optimistic new SSU2 schedule as:

Spec: 4Q 2021
Testing: 1Q 2022
Rollout: Mid 2022

As I said above, this would go faster if we had more help.

Wed, 18 Aug 2021, 01:35pm #13
zzz
Administrator
Zzz

In last week's meeting we talked at a high level about acks and ways to do it but didn't really zero in on the key issue. Notes to self:

Current acks are for _I2NP Messages_, either full or fragments. These messages have essentially random 4-byte IDs. If partial, a bitfield is included. Since an ack of one I2NP message doesn't imply an ack of previous ones (they are unordered), that makes congestion control much more difficult.

Wireguard is an encapsulation protocol and does not have acks at that layer, so it can't help us here.

To have a simpler congestion control, we need consecutive sequence numbers. The _UDP Packets_ have that in the (obfuscated) header, unless we go full ratchet tags (NO we don't want to do that).

So, thinking this through to its logical conclusion, should we be acking _UDP Packets_ instead of _I2NP Messages_ ? What are the implications of this?

Thu, 02 Sep 2021, 06:22pm #14
zab
I2P Legend

Just a few quick thoughts from me. Without sequence numbers flow-control algorithms are impossible to implement properly. What we have in SSU1 now is an approximation. In the testnet the SSU1 link is 15x slower than the NTCP2 link. So we're doing something very wrong.

I'm in favor of sticking to the RFCs (more specifically New Reno) and published papers (Westwood+) and not invent things. That means no NACKs, choking, probabilistic acking etc. unless there exists well-studied body of work on them.


email: zab@mail.i2p Irc2P/keybase: zlatinb
blog: http://zab.i2p
MuWire: http://muwire.i2p
MuCats: http://mucats.i2p
MuWire nickname: zlatinb@3k2gijdfdcuczkfypfddj4qsnnf744mj

Fri, 03 Sep 2021, 02:56pm #15
zzz
Administrator
Zzz

so.

In the last couple weeks what I've been exploring is using the sequential nonce in the packet header as the sequence number. We already have it, it's sequential, why not?

The problem is that not every packet has data. Some are ack-only packets, some may only have non-data blocks (peer test, relay request) that aren't acked (at least now, although I guess that could change in SSU2).

So this isn't going to work at all.

We can put sequence numbers in a separate field (block?) for packets that have data (I2NP) blocks. We could put a sequence number on each I2NP block. We could go back to acking I2NP messages as we do now. We could define large "frames" and ack those.

At this point I think we should take a step back and look for inspiration elsewhere. As we know, wireguard does not provide flow control, it's no help w.r.t. flow control.

A good first one to look at is QUIC https://en.wikipedia.org/wiki/QUIC and there's a few alternatives listed at the bottom of that page, including uTP, DTLS, ...

edit: now RFC 9000 https://datatracker.ietf.org/doc/html/rfc9000

Last edited: Fri, 03 Sep 2021, 03:02pm by zzz

Fri, 03 Sep 2021, 03:19pm #16
zzz
Administrator
Zzz

more thoughts:

QUIC is complex because it provides multiple streams per connection. We only need one.

Our transports are defined to send I2NP messages ONLY; they are not general-purpose data pipes.

From one angle, that's a complication.

But from another angle, it's a benefit. We don't need to count individual bytes, and we don't need to keep things in-order. We are allowed to deliver I2NP messages out-of-order, and we do that all the time. We can even drop I2NP messages completely without killing the connection.

These features may help us build a new transport more easily. Although it may complicate the flow control design.

Fri, 03 Sep 2021, 03:28pm #17
zzz
Administrator
Zzz

good stuff in QUIC sections:

8: Address Validation
9: Connection Migration
19: Frame Types (this is like our blocks)
21: Security Considerations

Fri, 03 Sep 2021, 03:32pm #18
zab
I2P Legend

I took a brief look at the links. I can't comment on the security aspects of the protocols, but from the perspective of flow control it basically boils down to two contenders: QUIC or LEDBAT(uTP).

QUIC is going to be more aggressive, whereas LEDBAT is more tuned to be a background protocol. This brings up an important non-technical but rather vision question: do we see I2P as running as a foreground or a background application? Will we win more users if eepsites open faster or will we lose more if users "feel" I2P is interfering with their other internet activity? Of the two I lean towards LEDBAT because I do not think the latency gains of QUIC are going to make a dent in the latency created by the multi-hop tunnels; also I don't see the need for multiple streams.

Or, we could choose the road more traveled and implement the most "vanilla" TCP we can. On the question what to number and what to ACK I would say number byte offsets of the stream just like TCP does.


email: zab@mail.i2p Irc2P/keybase: zlatinb
blog: http://zab.i2p
MuWire: http://muwire.i2p
MuCats: http://mucats.i2p
MuWire nickname: zlatinb@3k2gijdfdcuczkfypfddj4qsnnf744mj

Fri, 03 Sep 2021, 03:48pm #19
zzz
Administrator
Zzz

uTP (aka LEDBAT): http://www.bittorrent.org/beps/bep_0029.html

sequence numbers are for packets, not bytes
seq. num and ack nums in the header

the congestion control is odd, and I agree we're not exactly a yield-to-every-other-protocol type of application like BT is

<zzz> anyway, the congestion control stuff can be broken down into two parts, somewhat independent:
<zzz> 1) what do you put seq. nums on, what do they count (bytes, pkts, frames, I2NP msgs, ....)
<zzz> 2) the _algorithm_ itself (backoff, slow start, choking, acks/nacks, etc_

Last edited: Fri, 03 Sep 2021, 04:09pm by zzz

Thu, 09 Sep 2021, 07:00am #20
YesYesYes well maybe
I2P Legend

uTP (aka LEDBAT

I read the paper. It's sounds interesting and ideal.

Sun, 12 Sep 2021, 06:20pm #21
zzz
Administrator
Zzz

Update:

We're continuing to read other specs, including QUIC, uTP, and 'reliable multicast'. At this point we're still learning, and a long way from making any decisions.

As the work is expanding in several directions, we felt it was time to start the formal proposal document. Here it is:

http://i2p-projekt.i2p/spec/proposals/159

It's currently a mashup of the NTCP2 proposal, some threat model sections copied from QUIC, and a lot of placeholders so we can remember what we have to do. Skim it if you like but ignore the details.