From 27803361d381d8f9076fbc11b2637b00db4576a7 Mon Sep 17 00:00:00 2001 From: Christian Pointner Date: Sat, 9 Sep 2017 02:05:22 +0200 Subject: fix some typos --- NOTES | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) (limited to 'NOTES') diff --git a/NOTES b/NOTES index e145c51..e125609 100644 --- a/NOTES +++ b/NOTES @@ -22,17 +22,17 @@ sender-id/mux: |X ? ? ?| sender ID | MUX | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - X .. key exchange flag or unencrypted flag? + X .. key-exchange flag or unencrypted flag? ? .. reserved -Key-Exchange (inline): +inline Key-exchange: - Idea: Key-Exchange daemons can communicate with other side via link-local IPv6 + Idea: Key-exchange daemons can communicate with other side via link-local IPv6 addresses (works with tun and tap, at least on linux...) If packets incoming on tun/tap interface are IPv6 and have a link-local source - or destination IP, messages are sent to the other side unecrypted and with the - X flag set. + or destination IP, messages are sent to the other side unencrypted and with + the X flag set. Idea: use crypto role (server/client, left/right, alice/bob) for addressing @@ -43,7 +43,7 @@ Key-Exchange (inline): (xxxx is a well known number for SATP, i.e is always '5ADB') - Question: How to handle systems with IPv6 disabled? No inline Key-Exchange + Question: How to handle systems with IPv6 disabled? No inline key-exchange support in that case? IPv4 Link-local Adresses only have a /16 range and we would loose one mux value in that case (or 3 if we also omit network and broadcast addresses -> not too bad...) @@ -69,13 +69,13 @@ Key-Exchange (inline): Does this work together with the IPv6 Link-Local address idea from above? - Question: for the first key exchange it makes sense to update the remote + Question: for the first key-exchange it makes sense to update the remote address in the SA even if the received packets are unauthenticated, but during normal operation it is very bad to update the remote addresses, which are the result of authenticated packets, in favor of unauthenticated info (aka packets with X flag set). Idea: have a seperate address list for encrypted/authenticated packets and for - unauthenticated packets. If key exchange succeeds the addresses learned by it + unauthenticated packets. If key-exchange succeeds the addresses learned by it are copied to the address list for encrypted packets. @@ -89,7 +89,7 @@ Packet Handling (Marshal/Unmarshal): memory. This might even be 64k (the UDP maximum size) because there won't be a lot of them allocated at once (maximum one per NumCPU?!). Header, Payload and Authtag of EncryptedPacket as well as Type and Payload of - PlainPacket are go slices pointing to the underlaying buffer. TheHeader of + PlainPacket are go slices pointing to the underlaying buffer. The Header of EncryptedPacket und Type of PlainPacket have Getter and Setter which directly encode/decode using BigEndian.(Put)?Uint(16|32). All of this shouldn't need any mallocs and would therefor be pretty fast. -- cgit v1.2.3