Subject: [IPsec] Kathleen Moriarty's Yes on draft-ietf-ipsecme-tcp-encaps-09: (with COMMENT)

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 25 Apr 2017 13:55:34 -0700

Kathleen Moriarty has entered the following ballot position for
draft-ietf-ipsecme-tcp-encaps-09: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ipsecme-tcp-encaps/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you for documenting this practice to improve interoperability. 
This practice has been in place for a while and I think this is a helpful
document.  I have a few comments.

I think it would be good for the introduction to be more explicit on
where the problem lies that has resulted in this common practice of
tunneling this traffic through TCP.  The following sentence could be
modified:

OLD:
   Many network middleboxes that filter traffic on public
   hotspots block all UDP traffic, including IKE and IPsec, but allow
   TCP connections through since they appear to be web traffic. 

NEW (or something along these lines):
   Many network edge  middleboxes that filter traffic on public
   hotspots block all UDP traffic, including IKE and IPsec, but allow
   TCP connections through since they appear to be web traffic. 

I think it's important to note that this is happening at the edge in case
that is not clear enough with the phrase "public hotspots".   If it's
more than the edge where this is happening, and I'm not right about this
suggested change, please just say so.  

For section 11 - I think it's worth adding more text to hit on the
concerns Warren raised in one of his comments.  Here are some thoughts in
case it is helpful:
I agree with Warren that the result of operators not being able to
identify this traffic should be mentioned, although this is tricky.  The
port discussion in other AD reviews and discouraging the use of 443 may
change this to be identifiable traffic over TCP 4500 with the required
stream prefix only for legitimate uses, or in reality, 443 if this stays
undocumented because of existing implementations.  Warren commented on
operators not being able to detect this traffic is an important one, but
I think it's fine to say the intent is to circumvent ACLs or firewall
rules as opposed to avoiding detection.  Then saying that avoiding
detection is a result or unintended side effect.  
Side comment not intended for any new text:  It would be good if
operators observed the blocked ports (UDP 500) and figured out that they
should open the port, but this has been a problem for some time and not
all networks have dedicated operators (who want to fix this and similar
issues) or ones with the time and skill sets to fix the problem.

---

From: Paul Wouters <[email-masked]>
Date: Tue, 25 Apr 2017 22:10:37 -0400 (EDT)

On Tue, 25 Apr 2017, Kathleen Moriarty wrote:

[ Note at least Joe Touch seemed to think I'm an author. I am not. I
   meant the royal "we" as in the IPsecME WG. I have a vested interest
   because as an implementer I want an interoperable standard for this ]

> The port discussion in other AD reviews and discouraging the use of 443 may
> stream prefix only for legitimate uses

If you insist on this, one of two things will happen:

1) The landscape stays as fragmented and non-interoperable and it will
    hurt IKE/IPsec and we will see more SSL VPN varients and openvpn
    usage. No one will implement the resulting RFC.

2) Everyone will implement draft-ietf-ipsecme-tcp-encaps-09 which will
    never become an RFC.

> , or in reality, 443 if this stays

Could the ADs come up with the weasel words they and Joe Touch would
find acceptable? I don't get the idea there is agreement there.

Paul

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 25 Apr 2017 22:26:55 -0400

Hey Paul,

I'm reading through the comments and trying to think of ideas here....
and will continue to think about this a bit more, so I may have other
ideas tomorrow.  inline

> If you insist on this, one of two things will happen:

Note: I'm not insisting, but I see why other ADs are and I'm trying to
think about this as I understand the reality of the situation having
been responsible for these types of systems in the past.

For the port 443 usage, using TLS with a NULL cipher is the
recommended default in one example in the appendix.  Why don't you
just make this the method of connection when using 443 so that
HTTP/TLS is used and then 443 is appropriate.  You'd have to make this
consistent throughout the draft and have agreement for this change
with the WG, assuming it is ok technically.

This would mean that 4500 could still use the fallback basic TCP
encapsulation as the port doesn't have the same restrictions.

If you are using the expected protocols (HTTP/TLS on TCP 443), it gets
rid of the argument of reusing a port as you'd be using it for it's
intended purpose - just encapsulating something else.

> find acceptable? I don't get the idea there is agreement there.

I think some rewording is needed int eh document if others agree to
this approach and I think they should.  It limits the options for this
protocol, but still allows use of 443.

If you're asking about the other comment above, I can help with text,
but that's just simple descriptive text to state the purpose of this
more clearly and then the impact to operators (that might be the
operators of the middleboxes preventing UDP 500 or might be operators
at other points in the network).

-- 

Best regards,
Kathleen

---

From: Michael Richardson <[email-masked]>
Date: Wed, 26 Apr 2017 11:55:51 -0400

> find acceptable? I don't get the idea there is agreement there.

+1.  Paul speaks sense here.

"What do we want!"
"Secure connectivity now!"

"When do we want it?"
"Before IPv10 is deployed!"

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-