> >> [ 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. _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
