Hi, On 23/05/2020 23:35, Erik Kline wrote: > On Sat, May 23, 2020 at 2:24 PM Erik Kline <[email protected]> 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/ _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
