Re: [Int-area] draft-learmonth-intarea-rfc1226-bis-00

"Iain R. Learmonth" <> Sun, 24 May 2020 19:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3D37E3A09CA for <>; Sun, 24 May 2020 12:16:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.118
X-Spam-Status: No, score=-1.118 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 3JZ_8iK8EUPl for <>; Sun, 24 May 2020 12:16:37 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E2F463A09B9 for <>; Sun, 24 May 2020 12:16:35 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*", Issuer "Sectigo RSA Domain Validation Secure Server CA" (not verified)) by (Postfix) with ESMTPS id 49VVMR18CZzFcc3; Sun, 24 May 2020 12:16:35 -0700 (PDT)
X-Riseup-User-ID: B717201B06D14BBAB9701A0274AB307ACA7C0AD94DEC3E972CD24B2B4AC42DBC
Received: from [] (localhost []) by (Postfix) with ESMTPSA id 49VVMQ3QhLzJqk0; Sun, 24 May 2020 12:16:34 -0700 (PDT)
To: Erik Kline <>
References: <> <> <> <>
From: "Iain R. Learmonth" <>
Organization: HamBSD Project
Message-ID: <>
Date: Sun, 24 May 2020 20:16:31 +0100
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [Int-area] draft-learmonth-intarea-rfc1226-bis-00
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Internet Area Mailing List <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 24 May 2020 19:16:39 -0000


On 23/05/2020 23:35, Erik Kline wrote:
> On Sat, May 23, 2020 at 2:24 PM Erik Kline <> wrote:
> Ah, I think I see now that section 17 of that PDF refers to these as
> "dummy callsigns".  It mentions "TCPIP", but there doesn't seem to be
> any text significantly constraining these dummy callsigns.

Indeed. There is not currently a registry of these dummy callsigns. The
only restriction is that they should not be confused with real
callsigns, and this is achieved by using only alpha characters. ITU
requires that callsigns use numerals to separate the prefix from the
suffix to avoid ambiguity between countries.

>> [ section 5 ]
>> * Can you explain more about the limitations on non-NULL encryption?
>> My intuition would be that ESP with non-NULL encryption provides
>> privacy only on the IP links between tunnel endpoints.  A packet that
>> failed to decrypt properly would not be transmitted over the amateur
>> radio link, but rather be dropped by the IP endpoint (and possibly
>> logged).  I don't think I follow what the intent of this section is.

I think that the problem with this section is that I've not been clear
that everything relates to the path between the tunnel endpoints. The IP
packets, not just the AX.25 packets, may traverse an amateur radio link.
Microwave links using modified wifi equipment to operate in the amateur
bands are common, for example, and could carry an AX.25 tunnel over IP
between two AX.25 hosts. Encryption is forbidden on that IP microwave
link, just as it is on the AX.25 links.

I do not want to forbid the use of non-NULL encryption. This phrasing
may also be misleading as RFC4543 also provides encryption transforms
that do not provide confidentiality. Instead of talking about NULL
specifically, this could be changed to require use of a transform that
does not provide confidentiality.

Would these changes answer the question?

>> * I cannot find the phrase "dead peer detection" in RFC 7926, nor is
>> that the IKEv2 RFC.  I think perhaps you meant RFC 7296 (numeric
>> transposition).

Well caught! I did indeed mean the IKEv2 RFC.