Re: [IPsec] Ben Campbell's Discuss on draft-ietf-ipsecme-tcp-encaps-09: (with DISCUSS and COMMENT)

[Ben Campbell]

> On Apr 25, 2017, at 9:38 PM, Kathleen Moriarty 
>  wrote:
> 
> Thanks for the quick response Paul, a few questions...
> 
> On Tue, Apr 25, 2017 at 10:18 PM, Paul Wouters  wrote:
>> On Tue, 25 Apr 2017, Kathleen Moriarty wrote:
>> 
 IIUC, the entire point of having the stream prefix is to allow the TCP
 responder to demux between this protocol, and some other protocol that
 would normally run on that port. Saying it MUST close the TCP session
 seems to completely remove that value. I assume people meant to allow the
 respondent to delegate a stream out to some other protocol handler if the
 prefix is not present?
 
>>> 
>>> I believe that this is because there is presumed to be no other
>>> service operating on the listening port (assuming a VPN concentrator),
>>> but that's not explicitly stated either.
>> 
>> 
>> Vendors tend to run TLS on the IKE/IPsec machine, either to offer one of
>> the other kinds of SSL VPNs or as the administration interface or
>> user interface.
> 
> OK, sounds like I didn't help here, so the editors should propose text
> to address this gap.

I think we are on the right track here, pending proposed text.

> 
>> 
 -- 2nd to last paragraph: "This document leaves the selection of TCP
 ports up to implementations."
 I suspect "configurable local policy" would make more sense. Leaving it
 up to "implementations" leaves open the chance of different
 implementations making non-intersecting port choices, which doesn't help
 interoperability.
>>> 
>>> 
>>> This may go more into unexplained assumptions... the clients
>>> authorized to connect to the server would need to know the correct
>>> port to establish a session and would be given that information
>>> specific to the implementation.  With this assumption, the above
>>> should be fine... but editors/AD/WG, please correct me if I am wrong.
>> 
>> 
>> I am pretty sure what is meant is "configuration" and not "implementation".
> 
> Is that in response to me being wrong in my assumption or the draft
> should say configuration (I think it's the latter, but important to
> check)?

We are probably splitting hairs on the meaning of “implementation” vs 
“configuration”. (and maybe “deployment”). I was thinking of “implementation” 
as being what developers do, and “configuring/deploying” as what operators do. 
But I am aware that operators sometimes talk about “implementing” a system.

So my point was that I assume for purposes of interoperability that a general 
purpose client or server would allow the port to be changed in the field.

> 
>> 
 -4, first paragraph: What is the expected behavior from a peers that do
 not support this spec when they receive a TCP stream with the magic
 number on a port for some other protocol?
>>> 
>>> 
>>> Maybe listing assumptions up front in the draft would help _IF_ the
>>> assumption is that the listening server is a VPN concentrator that
>>> wouldn't be listening for other services.
>> 
>> 
>> Support for TCP would be based on preconfiguration, so the client knows
>> this out-of-band. It cannot be discovered during negotiation, because
>> it is assumed the regular UDP ports are blocked, which is the only
>> reason to attempt TCP to begin with.
> 
> I read the draft with this assumption in mind (see above), but this
> should be clarified in the document to address this question from Ben.

Imagine a misconfigured client opening a connection to an web server on port 
80, expecting to find a VPN service. What happens? I think that a consequence 
of the design approach to allow this to run over ports assigned to other 
protocols is that you need to consider that sort of thing.

>> 
 - Appendix A: Doesn't the use of the NULL cipher invalidate one of the
 primary reasons to use TLS? (Namely to obscure the fact that this is not
 HTTP, or whatever other protocol is assigned to the port?)
>>> 
>>> 
>>> Editors/AD correct me if I am wrong, but...
>>> No, if TLS is used with a NULL cipher, it'll pass inspection of a
>>> middle box validating the protocol.  This doesn't need to use the
>>> cipher as it's negotiating the IPsec connection.
>> 
>> 
>> right, TLS happens to use encryption to get out, but it is not the
>> encryption of the actual IKE/IPsec protocols, which keep using their
>> own channel negotiations.
> 
> I think clarifying this further in the draft would be helpful.

I agree, because I’m still confused :-) 

To clarify my question: Assuming the case of TLS encapsulation to the HTTPS 
port across a DPI middle-box that hates that sort of thing. If TLS uses the 
NULL cipher, can the middlebox not tell that the protocol over TLS is not HTTP? 
(I will defer to the experts.)


___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] regarding draft-ietf-ipsecme-tcp-encaps

[Yoav Nir]

> On 26 Apr 2017, at 0:15, Joe Touch  wrote:
> 
> First, correcting the subject line (sorry - that looks like an erroneous 
> paste on my part).
> 
> Also below...
> 
> On 4/25/2017 1:59 PM, Yoav Nir wrote:
>> Hi, Joe
>> 
>> I haven’t been involved with this draft, but I don’t believe that last 
>> statement is correct:
>> 
>>> On 25 Apr 2017, at 23:03, Joe Touch > 
>>> wrote:
>>> 
 
 This issue is really everyone circling around the elephant in the room.
 Part of this draft is designed to break through firewalls and
 middle-ware that only let out port 443 traffic unmangled. We cannot
 really write
 that we are doing this, despite everyone knowing we are doing this.
 
 Your suggestions that we need to not mention 443 without updating the
 RFC defining 443 is hard to meet. Not only because we'd have an IKE
 document updating a TLS document, but also because IANA actually has
 not RFC listed for the definition of port 443.
>>> 
>>> It's not listed, but it would probably be rfc2818 or one of the ones
>>> that updates that.
>>> 
>>> However, I'd personally want someone involved from HTTPWG to sign off on
>>> this.
>>> 
 I'm already a little annoyed that the draft cannot (politically) specify
 how to use port 443 with TLS to tunnel IKE and ESP over TCP.
>>> 
>>> Here's the thing:
>>> 
>>>You get to define your service.
>>> 
>>>You do not get to define someone else's.
>>> 
>>> You would be squatting (using someone else's ports for your purposes),
>>> pure and simple.
>> 
>> I don’t believe that TCP port 443 on the host at 192.0.2.7 “belongs” in any 
>> sense of the word to the HTTP working group.
> 
> Strictly, the port is assigned based on a service definition.
> 
> On any given host, any user can define any port any way they see fit, e.g., 
> they can run DNS on port 110 or IMAP on port 53.
> 
> However, a new standard should never be making a change to the service 
> defined for a port that is already assigned to another party (they can change 
> a service they have been assigned).
> 
>> While it is the default port for HTTPS, that protocol can run on any port 
>> depending on the value in origin (RFC 6454).
> 
> Yes, any protocol can run on any port number (as per above), as long as the 
> endpoints agree. But that's not what you're talking about here - you're 
> saying that if you get "IKETCP" on a port, then you can trust that it is your 
> service.
> 
> That's incorrect. You don't get to define the string "IKETCP" for other 
> services.

That I totally agree with.  The purpose of the IKETCP magic string is to 
demultiplex between TCP connections implementing this draft and other TCP 
connections using the same port for other services, regardless of whether those 
other services are defined in IANA or other squatters.

I think the text in section 4 already says so, but perhaps it can be clarified.

Yoav



signature.asc
Description: Message signed with OpenPGP
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] regarding draft-ietf-ipsecme-tcp-encaps

[Tommy Pauly]

> On Apr 25, 2017, at 2:15 PM, Joe Touch  wrote:
> 
> First, correcting the subject line (sorry - that looks like an erroneous 
> paste on my part).
> 
> Also below...
> 
> On 4/25/2017 1:59 PM, Yoav Nir wrote:
>> Hi, Joe
>> 
>> I haven’t been involved with this draft, but I don’t believe that last 
>> statement is correct:
>> 
>>> On 25 Apr 2017, at 23:03, Joe Touch > 
>>> wrote:
>>> 
 
 This issue is really everyone circling around the elephant in the room.
 Part of this draft is designed to break through firewalls and
 middle-ware that only let out port 443 traffic unmangled. We cannot
 really write
 that we are doing this, despite everyone knowing we are doing this.
 
 Your suggestions that we need to not mention 443 without updating the
 RFC defining 443 is hard to meet. Not only because we'd have an IKE
 document updating a TLS document, but also because IANA actually has
 not RFC listed for the definition of port 443.
>>> 
>>> It's not listed, but it would probably be rfc2818 or one of the ones
>>> that updates that.
>>> 
>>> However, I'd personally want someone involved from HTTPWG to sign off on
>>> this.
>>> 
 I'm already a little annoyed that the draft cannot (politically) specify
 how to use port 443 with TLS to tunnel IKE and ESP over TCP.
>>> 
>>> Here's the thing:
>>> 
>>>You get to define your service.
>>> 
>>>You do not get to define someone else's.
>>> 
>>> You would be squatting (using someone else's ports for your purposes),
>>> pure and simple.
>> 
>> I don’t believe that TCP port 443 on the host at 192.0.2.7 “belongs” in any 
>> sense of the word to the HTTP working group. 
> 
> Strictly, the port is assigned based on a service definition.
> 
> On any given host, any user can define any port any way they see fit, e.g., 
> they can run DNS on port 110 or IMAP on port 53. 
> 
> However, a new standard should never be making a change to the service 
> defined for a port that is already assigned to another party (they can change 
> a service they have been assigned).
> 
>> While it is the default port for HTTPS, that protocol can run on any port 
>> depending on the value in origin (RFC 6454).
> 
> Yes, any protocol can run on any port number (as per above), as long as the 
> endpoints agree. But that's not what you're talking about here - you're 
> saying that if you get "IKETCP" on a port, then you can trust that it is your 
> service.
> 
> That's incorrect. You don't get to define the string "IKETCP" for other 
> services. 
> 
>> The draft makes it clear in section 2 that the port used is pre-configured 
>> on both IKE initiator and IKE responder. The draft does not assign or 
>> re-assign any ports. 
> Section 4 claims that the use of the magic string differentiates this service 
> from the default assigned service or any other service. That's incorrect. You 
> don't have that authority.
> 
>> Yes, there is a suggestion to use port 443 because it is usable in more 
>> networks than other ports.
> Again, you don't have the authority to say what "IKETCP" means on port 443. 
> 
> Yes, if the port is explicitly indicated, you can use whatever port you want. 
> But you should never imply that this system should run on ports assigned to 
> other services that are running in parallel - you do not have that authority.
> 
>> That is why TCP port 443 has been used by Skype, AiCloud file sharing, Call 
>> of Duty, various “SSL VPN” products and many others. They’ve been doing that 
>> for over a decade. It is way too late to close the barn doors, and we don’t 
>> even have the authority to do so. 
> 
> You do not have the authority to endorse or standardize this behavior either.
> 
> It remains non-compliant squatting.
> 
>> We can remove all references to specific ports and leave only text about 
>> pre-configuration. IMO this amounts to a wind and a nod, because we all know 
>> which port is going to get configured.
> 
> You should be saying that the port is indicated explicitly (which is the 
> equivalent of pairwise endpoint negotiation) or use port 4500 (or maybe get 
> your own separate assignment). But the entire text on the magic number being 
> appropriate when sharing an existing assignment is incorrect and needs to be 
> removed IMO.

I suggest that we can:

- Clarify the text in section 2 (configuration) to say that the default port is 
TCP 4500, and that implementations may communicate other port options out of 
band as configuration. This is done for UDP as well. This is the "explicit" 
indication of the ports you mention above.
- Port 443 is only mentioned in the figures for the appendix. We can remove the 
mention of the port there.

As for the Stream Prefix of "IKETCP", I believe that we have good reasons to 
keep it even if we are only using the protocol on port 4500 (as would be the 
recommended/sanctioned) method. TCP port 4500 has been technically allocated to 

Re: [IPsec] Mirja Kühlewind's Discuss on draft-ietf-ipsecme-tcp-encaps-09: (with DISCUSS)

[Tommy Pauly]

> On Apr 25, 2017, at 5:48 AM, Mirja Kühlewind  wrote:
> 
> Mirja Kühlewind has entered the following ballot position for
> draft-ietf-ipsecme-tcp-encaps-09: Discuss
> 
> 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/
> 
> 
> 
> --
> DISCUSS:
> --
> 
> This draft suggests that ports that are assigned to other services can
> simply be used. This is not okay. If a port is assigned to a certain
> service, this service and/or the respective RFC defines how this port is
> used. Simply changing the specified behavior by requiring a check for a
> magic number cannot be done without updating the RFC that the port
> assignment belongs to. Also for the use of 4500/tcp RFC3948 as well as
> the IANA registry would need to be updated.

At this point, the only portion of the document that mentions a port other than 
500 and 4500 is the appendix. We recommend that 4500 is used as the port for 
TCP encapsulation. The IANA registry for 4500/tcp is already assigned to IPSec 
NAT Traversal in RFC 3947; that document does not explain how TCP is to be 
used, so the reference should be updated to point to the document on TCP 
encapsulation.

We can soften the references in the appendix to the fact that other ports may, 
in fact, be used. As for the configuration, it should state 4500 as the 
default, but allow peers to configure something else out-of-band if they want 
to modify behavior (which is standard even in UDP implementations of IKE).

> 
> Further, as also mentioned in the tsv-art review (Thanks Wes!), this
> draft does not sufficiently handle the case of TCP in TCP encapsulation.
> Here a copy of the tsv-art review:
> 
> Reviewer: Wesley Eddy
> Review result: On the Right Track
> 
> This document is clear and well-written.  It can easily be implemented
> based on the description.
> 
> There are a few additional issues that should be considered with
> advice to implementers in Section 12 on performance considerations:
> 1) Invisibility of packet loss - Inner protocols that require packet
> losses as a signal of congestion (e.g. TCP) will have a challenge due
> to not being able to see any packet losses since the outer TCP will
> repair them (unless sending into a full outer TCP socket buffer shows
> up back to the inner TCP as a packet loss?).

Yes, this is definitely true. We try to capture that with the line: "This will 
make loss-
   recovery of the inner TCP traffic less reactive and more prone to
   spurious retransmission timeouts."

However, this can certainly be expanded upon.

> 2) Nesting of ECN -  Inner TCP connections will not be able to use
> effectively ECN on the portion of the path covered by the outer TCP
> connection.

Generally, IPsec tunnels will apply RFC 6040 for translating ECN markings 
between inner/outer packets. Since TCP encapsulation places the inner IP 
packets in a stream, there isn't a direct mapping.

An implementation could try to roughly map, but it may be best to suggest that 
the ECN markings for inner and outer packets be left separate. What is your 
opinion?

> 3) Impact of congestion response on aggregate - The general "TCP in
> TCP" problem is mentioned, and is mostly appropriate for a single
> flow.  If an aggregate of flows is sharing the same outer TCP
> connection, there may be additional concerns about how the congestion
> response behavior impacts an aggregate of flows, since it may cause a
> shared delay spike even to low-rate flows rather than distributing
> losses proportional to per-flow throughput.

Indeed. We can add further comments to that effect.

> 4) Additional potential for bufferbloat - Since TCP does not bound
> latency, some applications in the IPsec-protected aggregate could
> drive latency of the shared connection up and impact the aggregate of
> flows that may include real-time applications.  The socket buffer for
> the outer TCP connection might need to be limited in size to ensure
> some bounds?

We can add a comment to suggest that the buffering should be limited on the 
outer connection if possible.

> 
> Not addressing these could lead to poor experiences in deployment, if
> implementations make wrong assumptions or fail to consider them.

I do think all of these concerns go back to the overall recommendation of "use 
direct ESP or UDP Encapsulation whenever possible". Anything to help back up 
that point is great!

Thanks,
Tommy
> 
> In the security considerations section, there 

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

[Kathleen Moriarty]

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

On Tue, Apr 25, 2017 at 10:10 PM, Paul Wouters  wrote:
> 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
>> change this to be identifiable traffic over TCP 4500 with the required
>> stream prefix only for legitimate uses
>
>
> 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.

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

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).
>
> Paul



-- 

Best regards,
Kathleen

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Ben Campbell's Discuss on draft-ietf-ipsecme-tcp-encaps-09: (with DISCUSS and COMMENT)

[Kathleen Moriarty]

Hi Ben & others,

I may be able to help on a few of these, but the editors (etc.),
please correct me if necessary.

On Tue, Apr 25, 2017 at 9:42 PM, Ben Campbell  wrote:
> Ben Campbell has entered the following ballot position for
> draft-ietf-ipsecme-tcp-encaps-09: Discuss
>
> 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/
>
>
>
> --
> DISCUSS:
> --
>
> I have one (hopefully easy) point that I think needs to be fixed before
> progressing.
>
> Section 6, paragraph 6 says : "... if the TCP Originator stream is
> missing the stream prefix, or message frames are not parsable as IKE or
> ESP messages), it MUST close the TCP connection."
>
> IIUC, the entire point of having the stream prefix is to allow the TCP
> responder to demux between this protocol, and some other protocol that
> would normally run on that port. Saying it MUST close the TCP session
> seems to completely remove that value. I assume people meant to allow the
> respondent to delegate a stream out to some other protocol handler if the
> prefix is not present?
>

I believe that this is because there is presumed to be no other
service operating on the listening port (assuming a VPN concentrator),
but that's not explicitly stated either.

>
> --
> COMMENT:
> --
>
> Substantive Comments:
>
> -2:
> -- 2nd bullet (and elsewhere)
> I think this needs a discussion about how those configured ports are
> likely to be in the assigned range, and the likely impact. (I recognize
> that tunneling over a port assigned to something else is a primary reason
> for doing this. I'm not arguing against it; I just think the implications
> warrant discussion.)
>
> -- 2nd to last paragraph: "This document leaves the selection of TCP
> ports up to implementations."
> I suspect "configurable local policy" would make more sense. Leaving it
> up to "implementations" leaves open the chance of different
> implementations making non-intersecting port choices, which doesn't help
> interoperability.

This may go more into unexplained assumptions... the clients
authorized to connect to the server would need to know the correct
port to establish a session and would be given that information
specific to the implementation.  With this assumption, the above
should be fine... but editors/AD/WG, please correct me if I am wrong.

>
> -3, first paragraph:
> Are people confident there will never, ever be a need to demux protocols
> other than IKE and ESP? If not, this approach may paint people in a
> corner in the future. I ask because we made similar choices with
> DTLS-SRTP [RFC5764] in demuxing DTLS and STUN, and it became an issue.
> See RFC7983 for a discussion. (Note that this would have been a DISCUSS
> point, but I think it's reasonably likely that there really won't be
> other protocols here. But I want to make sure people have thought about
> it.)
>
> -4, first paragraph: What is the expected behavior from a peers that do
> not support this spec when they receive a TCP stream with the magic
> number on a port for some other protocol?

Maybe listing assumptions up front in the draft would help _IF_ the
assumption is that the listening server is a VPN concentrator that
wouldn't be listening for other services.

>
> -6: First paragraph: It would be helpful to mention behavior on receipt
> of a stream without the magic number here. But see the DISCUSS point.
>
> -8: "... MUST support dynamically enabling and disabling TCP
> encapsulation..." seems unreasonably strong, especially since the
> requirement to try UDP before TCP is only a SHOULD. Does this contemplate
> situations where it might be impossible to use TCP on the after a network
> change?
>
> - Appendix A: Doesn't the use of the NULL cipher invalidate one of the
> primary reasons to use TLS? (Namely to obscure the fact that this is not
> HTTP, or whatever other protocol is assigned to the port?)

Editors/AD correct me if I am wrong, but...
No, if TLS is used with a NULL cipher, it'll pass inspection of a
middle box validating the protocol.  This doesn't need to use the
cipher as it's negotiating the IPsec connection.

>
> Editorial Comments:
>
> - Please expand IKE and ESP on first mention in both the abstract and
> body.

These are on the list of well known acronyms:
https://www.rfc-editor.org/materials/abbrev.expansion.txt

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

[Paul Wouters]

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
change this to be identifiable traffic over TCP 4500 with the required
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
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.


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

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

[IPsec] regarding draft-ietf-ipsecme-tcp-encaps

[Joe Touch]

First, correcting the subject line (sorry - that looks like an erroneous
paste on my part).

Also below...


On 4/25/2017 1:59 PM, Yoav Nir wrote:
> Hi, Joe
>
> I haven’t been involved with this draft, but I don’t believe that last
> statement is correct:
>
>> On 25 Apr 2017, at 23:03, Joe Touch > > wrote:
>>
>>>
>>> This issue is really everyone circling around the elephant in the room.
>>> Part of this draft is designed to break through firewalls and
>>> middle-ware that only let out port 443 traffic unmangled. We cannot
>>> really write
>>> that we are doing this, despite everyone knowing we are doing this.
>>>
>>> Your suggestions that we need to not mention 443 without updating the
>>> RFC defining 443 is hard to meet. Not only because we'd have an IKE
>>> document updating a TLS document, but also because IANA actually has
>>> not RFC listed for the definition of port 443.
>>
>> It's not listed, but it would probably be rfc2818 or one of the ones
>> that updates that.
>>
>> However, I'd personally want someone involved from HTTPWG to sign off on
>> this.
>>
>>> I'm already a little annoyed that the draft cannot (politically) specify
>>> how to use port 443 with TLS to tunnel IKE and ESP over TCP.
>>
>> Here's the thing:
>>
>>You get to define your service.
>>
>>You do not get to define someone else's.
>>
>> You would be squatting (using someone else's ports for your purposes),
>> pure and simple.
>
> I don’t believe that TCP port 443 on the host at 192.0.2.7 “belongs”
> in any sense of the word to the HTTP working group.

Strictly, the port is assigned based on a service definition.

On any given host, any user can define any port any way they see fit,
e.g., they can run DNS on port 110 or IMAP on port 53.

However, a new standard should never be making a change to the service
defined for a port that is already assigned to another party (they can
change a service they have been assigned).

> While it is the default port for HTTPS, that protocol can run on any
> port depending on the value in origin (RFC 6454).

Yes, any protocol can run on any port number (as per above), as long as
the endpoints agree. But that's not what you're talking about here -
you're saying that if you get "IKETCP" on a port, then you can trust
that it is your service.

That's incorrect. You don't get to define the string "IKETCP" for other
services.

> The draft makes it clear in section 2 that the port used is
> pre-configured on both IKE initiator and IKE responder. The draft does
> not assign or re-assign any ports.
Section 4 claims that the use of the magic string differentiates this
service from the default assigned service or any other service. That's
incorrect. You don't have that authority.

> Yes, there is a suggestion to use port 443 because it is usable in
> more networks than other ports.
Again, you don't have the authority to say what "IKETCP" means on port 443.

Yes, if the port is explicitly indicated, you can use whatever port you
want. But you should never imply that this system should run on ports
assigned to other services that are running in parallel - you do not
have that authority.

> That is why TCP port 443 has been used by Skype, AiCloud file sharing,
> Call of Duty, various “SSL VPN” products and many others. They’ve been
> doing that for over a decade. It is way too late to close the barn
> doors, and we don’t even have the authority to do so.

You do not have the authority to endorse or standardize this behavior
either.

It remains non-compliant squatting.

> We can remove all references to specific ports and leave only text
> about pre-configuration. IMO this amounts to a wind and a nod, because
> we all know which port is going to get configured.

You should be saying that the port is indicated explicitly (which is the
equivalent of pairwise endpoint negotiation) or use port 4500 (or maybe
get your own separate assignment). But the entire text on the magic
number being appropriate when sharing an existing assignment is
incorrect and needs to be removed IMO.

Joe
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] informal ports and transport review of ipsecme-cha...@tools.ietf.org

[Yoav Nir]

Hi, Joe

I haven’t been involved with this draft, but I don’t believe that last 
statement is correct:

> On 25 Apr 2017, at 23:03, Joe Touch  wrote:
> 
>> 
>> This issue is really everyone circling around the elephant in the room.
>> Part of this draft is designed to break through firewalls and
>> middle-ware that only let out port 443 traffic unmangled. We cannot
>> really write
>> that we are doing this, despite everyone knowing we are doing this.
>> 
>> Your suggestions that we need to not mention 443 without updating the
>> RFC defining 443 is hard to meet. Not only because we'd have an IKE
>> document updating a TLS document, but also because IANA actually has
>> not RFC listed for the definition of port 443.
> 
> It's not listed, but it would probably be rfc2818 or one of the ones
> that updates that.
> 
> However, I'd personally want someone involved from HTTPWG to sign off on
> this.
> 
>> I'm already a little annoyed that the draft cannot (politically) specify
>> how to use port 443 with TLS to tunnel IKE and ESP over TCP.
> 
> Here's the thing:
> 
>You get to define your service.
> 
>You do not get to define someone else's.
> 
> You would be squatting (using someone else's ports for your purposes),
> pure and simple.

I don’t believe that TCP port 443 on the host at 192.0.2.7 “belongs” in any 
sense of the word to the HTTP working group.

While it is the default port for HTTPS, that protocol can run on any port 
depending on the value in origin (RFC 6454).

The draft makes it clear in section 2 that the port used is pre-configured on 
both IKE initiator and IKE responder. The draft does not assign or re-assign 
any ports.

Yes, there is a suggestion to use port 443 because it is usable in more 
networks than other ports. That is why TCP port 443 has been used by Skype, 
AiCloud file sharing, Call of Duty, various “SSL VPN” products and many others. 
They’ve been doing that for over a decade. It is way too late to close the barn 
doors, and we don’t even have the authority to do so.

We can remove all references to specific ports and leave only text about 
pre-configuration. IMO this amounts to a wind and a nod, because we all know 
which port is going to get configured.

Yoav







signature.asc
Description: Message signed with OpenPGP
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Kathleen Moriarty]

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.


___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] informal ports and transport review of ipsecme-cha...@tools.ietf.org

[Joe Touch]

Hi, Paul,


On 4/25/2017 12:04 PM, Paul Wouters wrote:
> On Tue, 25 Apr 2017, Joe Touch wrote:
>
>> Ports issues:
>>
>> Every bit pattern, including those using magic numbers, is already
>> owned and under the control of each assigned port. It is not
>> appropriate for any new service to hijack that pattern as having a
>> different meaning UNLESS explicitly updating the service on
>> that port.
>>
>> A simple summary of what needs to change, in 2119-language:
>>
>>- this approach MUST NOT be described as applying to any assigned
>> number unless
>> also updating the associated RFC
>
> So it should add an Updates: RFC-3947

But also section 4 needs to be revised and the notion of the magic
string completely removed. You won't need a magic string if you use an
assigned port and you should NEVER be abusing (your words, below)
someone else's port for your purposes.

In fact, IMO, this doc should have a MUST NOT be used except with ports
specifically designated.

> It's a little weird. 3947 reserved TCP 4500, but did not specify how
> to actually use TCP at all. It seems it was mostly preventatively
> reserved.
That was IANA policy before RFC6335, when we shifted to "only assign
protocols actually in use".

>
>>- this approach MUST NOT be described as applying to any
>> unassigned but
>> assignable, or reserved port
>>
>>- this approach MUST NOT use any existing assigned port in an
>> example unless also
>> updating the associated RFC (including 4500 and 443)
>>
>> - IMO, this is a new service that therefore MUST either request a
>> new assignment (for
>> TCP only) or  be limited to operating only over dynamic ports, as per
>> RFC6335
>
> This issue is really everyone circling around the elephant in the room.
> Part of this draft is designed to break through firewalls and
> middle-ware that only let out port 443 traffic unmangled. We cannot
> really write
> that we are doing this, despite everyone knowing we are doing this.
>
> Your suggestions that we need to not mention 443 without updating the
> RFC defining 443 is hard to meet. Not only because we'd have an IKE
> document updating a TLS document, but also because IANA actually has
> not RFC listed for the definition of port 443.

It's not listed, but it would probably be rfc2818 or one of the ones
that updates that.

However, I'd personally want someone involved from HTTPWG to sign off on
this.

> I'm already a little annoyed that the draft cannot (politically) specify
> how to use port 443 with TLS to tunnel IKE and ESP over TCP.

Here's the thing:

You get to define your service.

You do not get to define someone else's.

You would be squatting (using someone else's ports for your purposes),
pure and simple.

I'm not sorry if that annoys you or you consider that politically incorrect.

> It will
> lead to interoperability issues because it is not specified. Becoming
> more quiet about port 443 isn't going to help anyone

It is - it protects HTTPS for the rest of us.

> and will only
> increase the large number of incompatible SSL-VPNs out there whose
> main reason for existing is that IKE/IPsec cannot leave some networks
> unless using abusing TLS over 443.

You said it - abusing. The IETF should never condone that behavior in a
new standard.

>
>> --
>> TCP issues:
>>
>> This approach has issues with its use of TCP as well, as follows:
>>
>> - TCP MSS has nothing to do with fragmentation; it is primarily
>> associated with IP reassembly
>
> I guess that text can be fixed.
>
>>- TCP over TCP discussion is insufficient; there are known
>> interactions that amplify the problem far beyond either one alone
>
> The text is already basically saying "tcp over tcp is such a disaster,
> really try to move back to udp as soon as possible and really try
> that often because tcp over tcp is really really bad". I don't know
> why more text is needed.

I agree this is less important - it's basically hurting yourself. I
think it's worth noting that the result is unpredictably worse than two
TCPs back to back, at least, though, as a warning to designers.

Joe

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] informal ports and transport review of ipsecme-cha...@tools.ietf.org

[Paul Wouters]

On Tue, 25 Apr 2017, Joe Touch wrote:


Ports issues:

Every bit pattern, including those using magic numbers, is already owned and 
under the control of each assigned port. It is not appropriate for any new 
service to hijack that pattern as having a different meaning UNLESS explicitly 
updating the service on
that port.

A simple summary of what needs to change, in 2119-language:

   - this approach MUST NOT be described as applying to any assigned number 
unless
also updating the associated RFC


So it should add an Updates: RFC-3947

It's a little weird. 3947 reserved TCP 4500, but did not specify how
to actually use TCP at all. It seems it was mostly preventatively
reserved.


   - this approach MUST NOT be described as applying to any unassigned but
assignable, or reserved port

   - this approach MUST NOT use any existing assigned port in an example unless 
also
updating the associated RFC (including 4500 and 443)

- IMO, this is a new service that therefore MUST either request a new 
assignment (for
TCP only) or  be limited to operating only over dynamic ports, as per RFC6335


This issue is really everyone circling around the elephant in the room.
Part of this draft is designed to break through firewalls and middle-ware 
that only let out port 443 traffic unmangled. We cannot really write

that we are doing this, despite everyone knowing we are doing this.

Your suggestions that we need to not mention 443 without updating the
RFC defining 443 is hard to meet. Not only because we'd have an IKE
document updating a TLS document, but also because IANA actually has
not RFC listed for the definition of port 443.

I'm already a little annoyed that the draft cannot (politically) specify
how to use port 443 with TLS to tunnel IKE and ESP over TCP. It will
lead to interoperability issues because it is not specified. Becoming
more quiet about port 443 isn't going to help anyone and will only
increase the large number of incompatible SSL-VPNs out there whose
main reason for existing is that IKE/IPsec cannot leave some networks
unless using abusing TLS over 443.


--
TCP issues:

This approach has issues with its use of TCP as well, as follows:

- TCP MSS has nothing to do with fragmentation; it is primarily
associated with IP reassembly


I guess that text can be fixed.


   - TCP over TCP discussion is insufficient; there are known
interactions that amplify the problem far beyond either one alone


The text is already basically saying "tcp over tcp is such a disaster,
really try to move back to udp as soon as possible and really try
that often because tcp over tcp is really really bad". I don't know
why more text is needed.

Paul



---

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec



___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

[IPsec] informal ports and transport review of ipsecme-cha...@tools.ietf.org

[Joe Touch]

Hi, all,

I'm providing this feedback at the request of the ADs.

The port information is based on my experience as IANA port review team lead.

The transport information is based on my experience in TSV-ART.

Joe



Ports issues:

Every bit pattern, including those using magic numbers, is already owned and 
under the control of each assigned port. It is not appropriate for any new 
service to hijack that pattern as having a different meaning UNLESS explicitly 
updating the service on
that port.

A simple summary of what needs to change, in 2119-language:

- this approach MUST NOT be described as applying to any assigned number 
unless
also updating the associated RFC

- this approach MUST NOT be described as applying to any unassigned but
assignable, or reserved port

- this approach MUST NOT use any existing assigned port in an example 
unless also
updating the associated RFC (including 4500 and 443)

- IMO, this is a new service that therefore MUST either request a new 
assignment (for
TCP only) or  be limited to operating only over dynamic ports, as per RFC6335

--
TCP issues:

This approach has issues with its use of TCP as well, as follows:

 - TCP MSS has nothing to do with fragmentation; it is primarily
associated with IP reassembly

- TCP over TCP discussion is insufficient; there are known
interactions that amplify the problem far beyond either one alone

---

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

[IPsec] Mirja Kühlewind's Discuss on draft-ietf-ipsecme-tcp-encaps-09: (with DISCUSS)

[Mirja Kühlewind]

Mirja Kühlewind has entered the following ballot position for
draft-ietf-ipsecme-tcp-encaps-09: Discuss

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/



--
DISCUSS:
--

This draft suggests that ports that are assigned to other services can
simply be used. This is not okay. If a port is assigned to a certain
service, this service and/or the respective RFC defines how this port is
used. Simply changing the specified behavior by requiring a check for a
magic number cannot be done without updating the RFC that the port
assignment belongs to. Also for the use of 4500/tcp RFC3948 as well as
the IANA registry would need to be updated.

Further, as also mentioned in the tsv-art review (Thanks Wes!), this
draft does not sufficiently handle the case of TCP in TCP encapsulation.
Here a copy of the tsv-art review:

Reviewer: Wesley Eddy
Review result: On the Right Track

This document is clear and well-written.  It can easily be implemented
based on the description.

There are a few additional issues that should be considered with
advice to implementers in Section 12 on performance considerations:
1) Invisibility of packet loss - Inner protocols that require packet
losses as a signal of congestion (e.g. TCP) will have a challenge due
to not being able to see any packet losses since the outer TCP will
repair them (unless sending into a full outer TCP socket buffer shows
up back to the inner TCP as a packet loss?).
2) Nesting of ECN -  Inner TCP connections will not be able to use
effectively ECN on the portion of the path covered by the outer TCP
connection.
3) Impact of congestion response on aggregate - The general "TCP in
TCP" problem is mentioned, and is mostly appropriate for a single
flow.  If an aggregate of flows is sharing the same outer TCP
connection, there may be additional concerns about how the congestion
response behavior impacts an aggregate of flows, since it may cause a
shared delay spike even to low-rate flows rather than distributing
losses proportional to per-flow throughput.
4) Additional potential for bufferbloat - Since TCP does not bound
latency, some applications in the IPsec-protected aggregate could
drive latency of the shared connection up and impact the aggregate of
flows that may include real-time applications.  The socket buffer for
the outer TCP connection might need to be limited in size to ensure
some bounds?

Not addressing these could lead to poor experiences in deployment, if
implementations make wrong assumptions or fail to consider them.

In the security considerations section, there are several RFCs on
mechanisms to increase robustness to RST attacks and SYN floods that
could be mentioned if it's worthwhile.




___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec