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

[Erik Kline <[e-mail]>]

> >> [ 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.