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

Erik Kline <> Mon, 25 May 2020 05:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F14643A0B85 for <>; Sun, 24 May 2020 22:20:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id oCx2b2Z0AvFm for <>; Sun, 24 May 2020 22:20:23 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::32e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 70BD33A0B9D for <>; Sun, 24 May 2020 22:20:10 -0700 (PDT)
Received: by with SMTP id g25so12956524otp.13 for <>; Sun, 24 May 2020 22:20:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=dKK/Ff5qeF8/xowF9ZrOAp9klO5SVGDQV+f4Kt9fVrA=; b=k5xEo5XCWbtUAudLAjHBkzYQaVHXUogKiOPDAmphWYY/EPs0NX48+o02n8nxl3imy9 llx1/jxWN4sZBM6sQZxvDvP5dapnoSMnW5CLevQYKiAEZWMfRMMPltnm46jUHryyM18Q 9uaRCDn/CyZ7hpbYQhEGrt7ojAFL8980YEyaUOTAIRsoTmGd0TQOgnna0yPZiJXcfp/O SrMZkKh3lkwPUTfmMXpFUBVVlNe+X2BsdwdnUcAGt7GUiUGLABMpbLMny+o/6FkJ1xR5 3Rshaj5dRc7EP12eQjdpUViQpmueldizDsXFOrTT45bU2W2IKSdcElUtKpbpWuEAt9jP FlOg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=dKK/Ff5qeF8/xowF9ZrOAp9klO5SVGDQV+f4Kt9fVrA=; b=lJTfb5LNUdwE1JZC16NT6QCdKck7GBR5U/lWplY4YwqMmZ3PKpCLVtL49/eJmUJ2vM Ue28HT5bABRB07bPRzoYdpBYoK74ZikhXDqR1xXCJdUR1jpiNvjvt3RPvOe9J3cDvODq KFsmZdVvMhsdT0BFI6w1S/o+kQ03KArcLARTMnOvQXd8ZnnChbNX0/N5gp6+CQ+4mMN8 DFQxMfTjZrflQ96gmaKo83rti5rrtbv2o1yvlZtd5AaXhiqDZFok0ZPinnwtEnMTiQ6x atFp46TvGDsf4zaKycBt74ZFI3+G3klflA5x/4Ub5fntpMKQ3rSbrpEL8sfN2cTmLSOh rVkw==
X-Gm-Message-State: AOAM533VPueou3dWy+arhQVFxSRhS/9AjNA1V9cymnah139LCaySs7rw OHMGZv4QO1BYJQuq2kd9aBW1i8w6yYpG/2ozKno=
X-Google-Smtp-Source: ABdhPJwWiQOUWflj8Qcd1vOT0JPTka/bQR5oQGU3fxnjSrB8YSKDb+tt42m9l66KYLzW/pMyUdwEt+4JvKsqSuoIAP8=
X-Received: by 2002:a9d:7f09:: with SMTP id j9mr17828316otq.144.1590384009392; Sun, 24 May 2020 22:20:09 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <>
In-Reply-To: <>
From: Erik Kline <>
Date: Sun, 24 May 2020 22:19:58 -0700
Message-ID: <>
To: "Iain R. Learmonth" <>
Content-Type: text/plain; charset="UTF-8"
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: Mon, 25 May 2020 05:20:26 -0000

> >> [ 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 think it might be good to call out that any traffic traversing AX.25
needs to be unencrypted due to $REGULATION or something.

Separately, it could be clearly stated that encryption is RECOMMENDED
for links that can be known (or reasonably expected) to not traverse
any AX.25 links.