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

["Iain R. Learmonth" <[e-mail]>]

Hi,

On 23/05/2020 23:35, Erik Kline wrote:
> On Sat, May 23, 2020 at 2:24 PM Erik Kline <[e-mail]> 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.

Thanks,
Iain.

-- 
https://hambsd.org/