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

[Tommy Pauly]

I'll defer to Tero on this one. Tero, what do you prefer to do with the IANA 
Considerations text?

Thanks,
Tommy

> On Apr 28, 2017, at 4:41 PM, Spencer Dawkins at IETF 
>  wrote:
> 
> This is still Mirja's Discuss (which I supported), so I'll let her respond to 
> most of Tommy's proposed text changes, but on the last one ...
> 
> On Fri, Apr 28, 2017 at 12:05 PM, Tommy Pauly  > wrote:
> 
> 14.  IANA Considerations
> 
>This memo includes no request to IANA.
> 
>TCP port 4500 is already allocated to IPsec for NAT Traversal.  This port 
> SHOULD
>be used for TCP encapsulated IKE and ESP as described in this document.
> 
> With no IANA actions, the entry in 
> https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=4500
>  
> 
>  for 4500/tcp will still point to http://www.iana.org/go/rfc3947 
>  as the reference. 
> 
> Should that change when this draft is published?
> 
> Thanks,
> 
> Spencer, who may be confused, but wanted to ask before the draft is approved

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

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

[Spencer Dawkins at IETF]

This is still Mirja's Discuss (which I supported), so I'll let her respond
to most of Tommy's proposed text changes, but on the last one ...

On Fri, Apr 28, 2017 at 12:05 PM, Tommy Pauly  wrote:

>
> 14.  IANA Considerations
>
>This memo includes no request to IANA.
>
>  *  TCP port 4500 is already allocated to IPsec for NAT Traversal.  This
> port SHOULD*
> *   be used for TCP encapsulated IKE and ESP as described in this
> document.*
>

With no IANA actions, the entry in
https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=4500
for 4500/tcp will still point to http://www.iana.org/go/rfc3947 as the
reference.

Should that change when this draft is published?

Thanks,

Spencer, who may be confused, but wanted to ask before the draft is approved
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Tommy Pauly]

Hello all,

Here's some proposed text for:

- Clarifying the configuration model around ports
- Clarifying the role of the stream prefix
- Expanding the TCP performance considerations. 

Changes are in bold.

Thanks,
Tommy

---

2.  Configuration

   One of the main reasons to use TCP encapsulation is that UDP traffic
   may be entirely blocked on a network.  Because of this, support for
   TCP encapsulation is not specifically negotiated in the IKE exchange.
   Instead, support for TCP encapsulation must be pre-configured on both
   the TCP Originator and the TCP Responder.

   Implementations MUST support TCP encapsulation on TCP port 4500, 
   which is reserved for IPsec NAT Traversal. 

   Beyond a flag indicating support for TCP encapsulation, the configuration
   defined on each peer can include the following optional parameters:

   o  Alternate TCP ports on which the specific TCP Responder listens for
  incoming connections.  Note that the TCP Originator may initiate
  TCP connections to the TCP Responder from any local port. 

  ...

4.  TCP-Encapsulated Stream Prefix

   Each stream of bytes used for IKE and IPsec encapsulation MUST begin
   with a fixed sequence of six bytes as a magic value, containing the
   characters "IKETCP" as ASCII values.  This value is intended to identify
   and validate that the TCP connection is being used for TCP encapsulation
   as defined in this document, to avoid conflicts with the prevalence of 
previous
   non-standard protocols that used TCP port 4500. This value is only sent 
once, 
   by the TCP Originator only, at the beginning of any stream of IKE and ESP 
messages.

...

12.  Performance Considerations

   Several aspects of TCP encapsulation for IKE and IPsec packets may
   negatively impact the performance of connections within a tunnel-mode
   IPsec SA.  Implementations should be aware of these and take these
   into consideration when determining when to use TCP encapsulation.
   Due to these performance impacts, implementations SHOULD favor using 
   direct ESP or UDP encapsulation over TCP encapsulation whenever
   possible.


12.1.  TCP-in-TCP

   If the outer connection between IKE peers is over TCP, inner TCP
   connections may suffer effects from using TCP within TCP.  Running
   TCP within TCP is discouraged, since the TCP algorithms
   generally assume that they are running over an unreliable datagram
   layer.

   If the outer (tunnel) TCP connection experiences packet loss, this loss
   will be hidden from any inner TCP connections, since the outer connection
   will retransmit to account for the losses. This means that loss on an outer 
   connection will be interpreted only as delay by inner connections. Since
   the outer TCP connection will deliver the inner messages in order, any 
messages
   after a lost packet may have to wait until the loss is recovered. This 
increases
   the burstiness of inner traffic, since a large number of inner packets will 
be delivered
   across the tunnel at once. This effect is especially of concern when there 
is a high 
   level of loss on the outer connection.

   TCP-in-TCP can also lead to increased buffering, or bufferbloat. This can 
occur when the
   window size of the outer TCP connection is reduced, and becomes smaller than 
the window
   sizes of the inner TCP connections. This can lead to packets backing up in 
the outer TCP
   connection's send buffers. In order to limit this effect, the outer TCP 
connection should have
   limits on its send buffer size, and on the rate at which it reduces its 
window size.

   The inner TCP's round-trip-time estimation will also be affected by the 
burstiness of the outer 
   TCP connection.  This will make loss-recovery of the inner TCP traffic less 
reactive and more
   prone to spurious retransmission timeouts.

   Note that any negative effects will be shared between all flows going 
through the outer TCP
   connection. This is of particular concern for any latency-sensitive or 
real-time applications 
   using the tunnel. If such traffic is using a TCP encapsulated IPsec 
connection, it is recommended
   that the number of inner connections sharing the tunnel be limited as much 
as possible.

...

12.5.  Tunnelling ECN in TCP

   Since there is not a one-to-one mapping between outer IP packets and inner 
ESP/IP messages
   when using TCP encapsulation, the markings for Explicit Congestion 
Notification (ECN) cannot
   be simply mapped. However, any ECN markings on inner messages should be 
preserved through
   the tunnel.

   Implementations SHOULD follow the ECN compatibility mode as described in RFC 
6040. The
   outer TCP connection SHOULD mark its packets as not ECN-capable, but SHOULD 
NOT clear
   any ECN markings on inner packets.

...

14.  IANA Considerations

   This memo includes no request to IANA.

   TCP port 4500 is already allocated to IPsec for NAT Traversal.  This port 
SHOULD
   be used for TCP encapsulated IKE and ESP 

Re: [IPsec] small correction : draft-abad-i2nsf-sdn-ipsec-flow-protectio

[Gabriel Lopez]

Hi Sandeep,


> El 26 abr 2017, a las 11:26, Sandeep Kampati  
> escribió:
> 
> Hi All,
> 
> small correction
> 
> 8.  Data model
> 
>   Data model for the SDP entries: --> it should be"Data model for the 
> SPD entries: “


Thanks.
We expect to have a new version in the next days.

Regards, Gabi.

> 
> Regards,
> Sandeep.k
> 
> 
> 
> ___
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec

---
Gabriel López Millán
Departamento de Ingeniería de la Información y las Comunicaciones
University of Murcia
Spain
Tel: +34 86504
Fax: +34 868884151
email: gab...@um.es

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

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

[Mirja Kühlewind]

Hi Tero,

a few quick replies but we also discussed this yesterday at the telechat and 
agreed on a way forward.


On 27.04.2017 16:12, Tero Kivinen wrote:

Mirja Kühlewind writes:

I agree that this kind of port squatting is regrettable, but I also don't
think it really
helps to not publish RFCs that document widely used protocols because we
are sad they port-squatted.

I proposed a way to deal with this in an earlier e-mail. Would that be
satisfactory
to you. To retransmit, we add the following

"Note: While port 4500 is the reserved port for this protocol, some existing
implementations
also use port 443. The Stream Prefix provides some mitigation against
cross-protocol
attacks in this case, however, the use of port 443 is NOT RECOMMENDED"

We could do something similar for port 80.

Would that work?


This already is good but I think it's not enough. As Tero noted the working
group thought that they rather specify a generic scheme which I find
problematic. Currently the drafts says:

"This document leaves the selection of TCP ports up to
implementations.  It is suggested to use TCP port 4500, which is
allocated for IPsec NAT Traversal."

Which sounds to me like an invitation to squat on any open port regardless
what the port is supposed to be used for (hoping that the magic number would
avoid any collision). I don't think that a good thing to right in an RFC.


Note, that configurations can only use ports which are defined to be
used by the responder. I.e., if the responder is configured to listen
port 4500 and port 443 (with TLS wrapping), there is no point of
initiator to try port 80, as it will not work.


I understood this. My point breaks down to a) the case where you would use 
two services at the same time on the same port (see below) and b) some 
language changes that do favor to use 4500 where possible and not explicitly 
advise to use other assigned specific ports in the line of what Ekr already 
proposed.




I.e., in practice this will end up the operators picking suitable
number of port numbers they will configure their system to respond to,
and most likely they will try to use services which are not in use
normally by the responder. I.e., if the responder is running
web-server, it cannot very easily also use the port 80 (or 443) for
the IPsec traffic, thus it might pick ports 4500, 8000, 8080 or some
other random ports which might go through the filters which are
already blocking all UDP traffic, and at least port 4500 for TCP.


Actually this is another good point. If you have multiple open ports, you can 
give more advise which one to try when and in which order, e.g. always try 
4500 first (first UDP then TCP which the draft I believe already says), then 
others.




So this is same thing we have now in web. I am quite often running web
servers on random ports just because some places have had filters
blocking some ports. For example one of my friends company network
blocked connection to port 8080, but did not block connections to port
2020, so my web server was running (also) on that port...

So unless you are saying "TCP/UDP ports on all protocols MUST NOT be
configurable, and only port numbers reserved for those services are
allowed" there is nothing we can really do.

(and even if you say that, nothing is going to change, as people are
so used to getting past stupid firewalls).


Now given the text you propose above, I actually assume that the text I just
cited will be removed but the whole document is written with this assumption
and therefore there are a couple more places where wording probably needs to
change.

I do understand well the problem and that 443 is used in practice. However,
to match reality I would rather like to see a document that specifies the
approach of encapsulating in TLS/TCP on port 443 that is used today and pure
TCP encapsulation for use with port 4500 only. Again i think that's where
your proposed text is heading to but I think it needs more changes; in this
case it would also make sense to add the TLS part back in the main document
for 443 only.


This is what the document tries to say. I.e., for some ports (like
443), there might be some other framings (like TLS) in place, and for
other ports there might not be. As IPsec will require
pre-configuration this information which ports are used, and what
framing protocol is used comes from the configuration.


Further, I have one more question: The document is written in a way that
allows the implementation of multiple services on the used port. Is that
actually done in reality?


Yes and no. There are some old IKEv1 based proprietary TCP
encapsulation methods, and I think some of those might actually use
port 500 and perhaps also port 4500. So vendor implementing those,
might want to do multiplexing based on whether there is the stream
prefix in front or not to see whether the old proprietary method is
used, or the one defined in document is used.


There is a difference of distinguishing other/old