Re: [OPSAWG] Christian's review of draft-mm-wg-effect-encrypt-13

[Kathleen Moriarty <[e-mail]>]

Hello James,

Thank you for your review and suggestions, responses are inline.

On Fri, Dec 8, 2017 at 1:53 PM, james woodyatt <[e-mail]> wrote:
> On Dec 4, 2017, at 08:23, Christian Huitema <[e-mail]> wrote:
>>
>> In section 2.3.3, Application Layer Gateways, I was wishing it would say
>> something about IPv6. But then of course most IPv6 deployments today
>> involve a form of NAT64...
>
> That section leaves unmentioned a vast array of open questions related to IPv6-layer security filters and the problem of application layer gateways.

If there are specific problems that are encountered with session
encryption that you think should be added, please provide text and
explain if it is with encryption that leaves a 5-tuple or 2-tuple
available and what other metadata is typically used.

>
> It contains an extended discussion of the ALG functions in one example case-- and not a particularly good one I would say-- the RTSP protocol, which in the presence of an ALG, depends on the parties performing it in cleartext, or it alternatively requires a proxy being a participant in the security protocol. The issues it describes apply to RTSP over both IPv4 and IPv6 in the presence of stateful filters that deny unsolicited inbound flows. Both NAT44 and NAT64 depend on such stateful filters, and "Simple Security in IPv6 Gateway CPE” [RFC 6092] is an example of a place where the issue applies in the absence of any network address translation.

Hmm, we do have text elsewhere in the draft on the problems with RSTP
for operators.  In looking at RFC6092, that is specific to small
offices and home gateways, which we don't cover in this draft.  Since
the issues are already covered in that RFC, are you suggesting an
addition here?  I'm not sure it's a fit.

>
> Some history might be worth recalling here, at the risk of yet again being That Guy Who Told You So.
>
> Because I’m a bitter old man, I like to go back to “Local Network Protection for IPv6” [RFC 4864]. Specifically, §4.2 IPv6 and Simple Security. This document, while Informational, is the point in our history where IETF formally published a statement acknowledging that IPv6 would absolutely always have the same problem with needing trustworthy ALGs and proxies in the network that IPv4 does.

I think this also boils down to architectural decisions.  There are
ways to perform many of the functions multiple ways, this document
doesn't go much into the alternate option of proxying the encrypted
traffic since that will still be possible with TLS 1.3.

>
> The key sentence there is this one:
>
>>> These should provide a default configuration where incoming traffic is limited to return traffic resulting from outgoing packets (sometimes known as reflective session state).
>
> After this document was published, and the howling subsided, some of us thought it would be a good idea to describe the behavioral requirements of this IPv6 "Simple Security" function in the same way that RFC 4787 and RFC 5382 do for UDP and TCP, respectively, in the IPv4/NAT case. Which is why we now have "Simple Security in IPv6 Gateway CPE” [RFC 6092].
>
> When RFC 6092 was in development, an early draft revision had a section about recommendations for various application layer gateways, e.g. RTSP+RTP, L2TP+IKE+IPsec/ESP, FTP, et cetera. The final draft didn’t include any of that, because consensus emerged around the idea that IPv6 simple security functions should not *need* any ALGs, and they should instead include a generic service for applications to use in soliciting inbound flows from unknown remote addresses. This entailed having the usual IETF tussle over competing non-standard solutions, i.e. UPnP-IGD vs. NAT-PMP. It was unresolved at the time RFC 6092 was published. It would still take some time before "Port Control Protocol (PCP)" [RFC 6887] would settle that debate.
>
> Which is why REC-48 is written with such curiously vague text:
>
>>> Internet gateways with IPv6 simple security capabilities SHOULD implement a protocol to permit applications to solicit inbound traffic without advance knowledge of the addresses of exterior nodes with which they expect to communicate.
>
> Were we to revise RFC 6092 today, I would like to see this amended to recommend PCP specifically. If there is an RFC anywhere that specifically asserts that deploying PCP servers in NAT64 and IPv6 firewall devices is Best Current Practice, then I’m unaware of it. It would be nice.

I'm not aware of one either, I don't think that exists.

>
> With hindsight, I was right to harbor pessimism about the rosy predictions, favored by some IETF participants, for the future of IPv6 without simple security gateways everywhere, entailing the need for an array of ALGs and proxies in every gateway, with the consequential impediment to application protocol evolution created thereby. It turns out that “Local Network Protection for IPv6” [RFC 4864] really was a BCP in an Informational drag, which is the case I remember making here all those years ago.
>
> With respect to NAT64, it’s worth reviewing “NAT64 Deployment Options and Experience” [RFC 7269], which is Informational, and it discusses both PCP and "An FTP Application Layer Gateway (ALG) for IPv6-to-IPv4 Translation” [RFC 6384], as an example of a case where we recognized that ubiquitous stateful filtering and denial of unsolicited inbound flows would entail the placement of application layer gateways and proxies in the network. Why do IPv6 FTP clients require RFC 6384? Because they don’t have PCP clients in them, and there are no PCP servers anyway.
>
> Now it’s almost 2018, and we are finally discovering that pervasive encryption requires ALGs and proxies to be trusted by all parties in the application protocol. And this is painful. Because new host application protocols aren’t even developed to use PCP. Because PCP servers haven’t been deployed anywhere. Because everything is terrible, and everyone would love to keep it that way. Or, at least, it seems so to me. Because I’m a bitter old man.
>
> I honestly don’t know if there is anything useful to say about ALGs in this document beyond simply acknowledging somewhere that they’re all necessarily broken by pervasive end-to-end encryption and operators who value administrative privacy, user tracking and/or topology hiding should consider the utility of secure application level proxies instead.

Thanks for your input.  We are not including solutions in the draft
intentionally (as much as possible).  If you have specific text about
ALGs that should be added, please do provide it, but please have it
specific to the goals of the draft - documenting the function impacted
by encryption and the data used currently when sessions are not
encrypted so there can be some assessment of impact.  Of course the
use of proxies are slower than many other solutions and not always an
option or good idea.

>
>
> --james woodyatt <[e-mail]>
>
>
>



-- 

Best regards,
Kathleen