From nobody Thu Jan 16 20:31:01 2025 X-Original-To: freebsd-net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4YYvdr3K9Zz5ksvk for ; Thu, 16 Jan 2025 20:31:12 +0000 (UTC) (envelope-from fakedme+freebsd@gmail.com) Received: from mail-pl1-x631.google.com (mail-pl1-x631.google.com [IPv6:2607:f8b0:4864:20::631]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4YYvdr1Ym0z3xQP for ; Thu, 16 Jan 2025 20:31:12 +0000 (UTC) (envelope-from fakedme+freebsd@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pl1-x631.google.com with SMTP id d9443c01a7336-21631789fcdso32295395ad.1 for ; Thu, 16 Jan 2025 12:31:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1737059471; x=1737664271; darn=freebsd.org; h=in-reply-to:from:content-language:references:cc:to:subject :user-agent:mime-version:date:message-id:sender:from:to:cc:subject :date:message-id:reply-to; bh=Afq1+tNmo646RM1+hZiQXlHBs2mE1w9l+r1H7UnbQFY=; b=bYI55XMqpKmfZkVxAUy0Cg9TGmYq3yRsS9z3gn+V9QlgGbyqY2y8Vjam5nAv3fEFET jpiYUxp+dyt5qMoTD5Hf0uGYlTXhy8zdmFdw714H96rlcytNdaE9JJy1EZMcGUgkSgvl ElsTXeH9x0H4cGzDGS3zCQOsN8gXFjt04eXmkxi+T2Ml4m2MOhHJq/OIYa+HacB/ELKh c4EKWtTBpaHBb8vRF19jsEwj95F1OafeMsKMbNyCMiZHDR85+gszDXkklRJEbNJAccLO ykEBx+QVQkIkMtO5SfW4mq4YAYVLqthEO2QcVQTGWRvkVUcsj+iBqjCpl4iyS2HEmwho m/QQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1737059471; x=1737664271; h=in-reply-to:from:content-language:references:cc:to:subject :user-agent:mime-version:date:message-id:sender:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=Afq1+tNmo646RM1+hZiQXlHBs2mE1w9l+r1H7UnbQFY=; b=TdI3fWXAF/GZLVWyy8NrxbeKew6EkzWy/tXJ4RduKc8NXQSsJF0Xfnaga/t+Hg33Dd ABRwLH/9teXZhBjoBy7SKxCuJLaGflKblsqZ6qXx4uh9i3u530v0ASKjGavGQAWihhPC pfZPGNYk4UmIjRzBVdlXRHl5MIF2OTHtBDPRQS7uz1Yv/OttfBRXUICQ/bY6vFO7fo52 sQYeALY2OpobXAHPp8lePnGf63ITFNLYh8GdOoI+TzBC2rRzCVwP05YlKdqErBrcUdi4 bklR8NHDHr/MvtPlXjigxZ5rBKdqoMqDuNHlr/2tc/6fxUksf7V77xKp9+JSYTzYhdpi kPrw== X-Gm-Message-State: AOJu0Yxt+H+t5tV7nmXq8ml1y3T2HaxCEl+AEXPLUgrfQ6NEhW/OwWZL zzI3XxuRMEq1V1KUXzcH7aPtll/NMUG5fvd+y2kY9oHAWtdVfxKz X-Gm-Gg: ASbGnctG6OH13cPZGvOfpEPUDQi78PiYI2hPkxlGuAwEFV3Xs5lEHvehmGmhUeUbD21 rmITrlz6vxPgsOS0wnkqtp/vfd/0d0PQtdjWg8AcR0x1AiWXuL0esNhpHEQABkkmtXbWEo1RJ7j rgJuKJUWq3KaTP2soK59DQWMrO95+J6gnfGhVEeZ1Fcm+ymRX9cq9KL09++POjvsaiF4xD1QOvT wZdlvcLhZ/T6n/epMVVxlN0x6qPFW/64Qsp+s57FKd6i7USkKDbIVQSVmYaQfgFurCyqbtUbzDS RtSEeIOkqEk= X-Google-Smtp-Source: AGHT+IGunAzKPv4lj36CMA7tpW0aaKm1PX6LqWLMj74pf60JwIfp59Js818pwiMw6RNaFJMiIaTTFg== X-Received: by 2002:a05:6a00:2d11:b0:725:ebc2:c321 with SMTP id d2e1a72fcca58-72d8c4ae92dmr15680886b3a.4.1737059470843; Thu, 16 Jan 2025 12:31:10 -0800 (PST) Received: from ?IPV6:2804:1b1:fc80:270f::536f:6e69? ([2804:1b1:fc80:270f::536f:6e69]) by smtp.googlemail.com with ESMTPSA id 41be03b00d2f7-a9bdd02b954sm440964a12.52.2025.01.16.12.31.08 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 16 Jan 2025 12:31:10 -0800 (PST) Content-Type: multipart/alternative; boundary="------------TnUqIKRLHzXkVD5mICATBJ6o" Message-ID: Date: Thu, 16 Jan 2025 17:31:01 -0300 List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@FreeBSD.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: ipsec as an address family To: Vadim Goncharov Cc: freebsd-net@freebsd.org References: <20250116225743.3bffd39f@nuclight.lan> Content-Language: en-US From: "Soni \"It/Its\" L." In-Reply-To: <20250116225743.3bffd39f@nuclight.lan> X-Rspamd-Queue-Id: 4YYvdr1Ym0z3xQP X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; TAGGED_FROM(0.00)[freebsd]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] This is a multi-part message in MIME format. --------------TnUqIKRLHzXkVD5mICATBJ6o Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 2025-01-16 16:57, Vadim Goncharov wrote: > Could you provide technical overview, both from API and packet format side, at > least briefly? > packet format is just regular ipsec, there are no protocol changes required! API... we're currently thinking the sockaddr_ipsec struct would take a key (appropriate for the task, e.g. public key for connect, private key for bind). we're however not so certain about the private key part, but at least for connecting, it makes sense to just take the public key of the target. ideally we would also be able to request just authentication, just encryption, or both, tho we're not entirely sure how the API should look (authentication-only is the most useful to us, as we're just trying to prevent port scanning and most modern protocols (TLS, SSH, minecraft server protocol, etc) provide their own encryption anyway). it's not unusual to have an asymmetry between connect and bind, as an example, port 0 is reserved for connect but lets the OS pick a port for bind. --------------TnUqIKRLHzXkVD5mICATBJ6o Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

On 2025-01-16 16:57, Vadim Goncharov wrote: 
Could you provide technical overview, both from API and packet format side, at
least briefly?

packet format is just regular ipsec, there are no protocol changes required!

API... we're currently thinking the sockaddr_ipsec struct would take a key (appropriate for the task, e.g. public key for connect, private key for bind). we're however not so certain about the private key part, but at least for connecting, it makes sense to just take the public key of the target. ideally we would also be able to request just authentication, just encryption, or both, tho we're not entirely sure how the API should look (authentication-only is the most useful to us, as we're just trying to prevent port scanning and most modern protocols (TLS, SSH, minecraft server protocol, etc) provide their own encryption anyway).

it's not unusual to have an asymmetry between connect and bind, as an example, port 0 is reserved for connect but lets the OS pick a port for bind.
--------------TnUqIKRLHzXkVD5mICATBJ6o--