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

[Ben Campbell]

> On Apr 27, 2017, at 7:09 AM, Tero Kivinen  wrote:
> 
 Substantive Comments:
 
 -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.)
>>> 
>>> If we ever want to run other protocols there, we still have 255
>>> reserved values we can use as Non-ESP marker. The reason the
>>> 0x is selected as Non-ESP marker in the UDP encapsulation (and
>>> here) is because first four octets of the ESP packet are SPI, and SPI
>>> MUST NOT be zero. Also numbers from 1 to 255 are "are reserved by the
>>> Internet Assigned Numbers Authority (IANA) for future use" in the
>>> RFC4303.
>>> 
>>> So if we need to run something else than IKE and ESP over that tunnel
>>> we just reserve one of the other reserved IANA numbers for it and use
>>> it as protocol marker for this new protocol. 
>> 
>> Ah, I didn’t realize 1-255 were reserved. It might be worth a
>> mention that if future protocols are added, their prefixes must be
>> registered with IANA. (I note that 2 are registered already.)
> 
> I do not think it belongs to this document. This is not actually using
> reserved SPIs, but I think it should be enough to see that there is a
> way to extend this, but as we do not see the need for extension now,
> we do not need to think how we are going to do it. There are other
> ways of doing that extension also and everything depends what we
> really want to do.
> 
> Trying to guess things now is not really useful.

The reason I thought it might be worth mentioning it would be to help prevent 
people from heading down a wrong path in future extensions. I’m okay with 
leaving it out if people think the probability of it coming up is low.


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

Re: [IPsec] Can IPSec (RFC 5996) support tunnels with end point being (virtual) CPEs which has a set of workload attached (say Virtual Machines) all having virtual IP addresses?

[Rafa Marin Lopez]

Hi Paul:

Thank you for your comments. Please, see mine inline.

>>> [Rafa] I guess, it will depend on the scenario. I remember an e-mail to 
>>> I2NSF (https://www.ietf.org/mail-archive/web/i2nsf/current/msg0.html) 
>>> mentioning that they were doing sort of case 2 and they would like to have 
>>> a standard way of doing it. Precisely the effort behind our I-D is trying 
>>> to provide an standard interface standard not only for case 1 (with IKE in 
>>> the NSF) but also for case 2 (no IKE in the NSF). 
>>> 
> 
> Don't. You will need to builtin there same security features as IKE has.

[Rafa] Yes, but in case 2 all those features (e.g. key management operations) 
are in the controller but not in the NSFs. The NSFs only implements IPsec stack 
and deploys, for example, a NETFCONF server for the communication with the 
controller. Thus, all the key management operations are performed in the 
controller in case 2 and the resulting IPsec SAs are installed in the NSFs 
using, for example, NETCONF. 

> Focus instead of implementing "minimal ikev2"
> 
> https://tools.ietf.org/html/draft-kivinen-ipsecme-ikev2-minimal-01

[Rafa] Minimal IKEv2 implementation in the NSF would be case 1. 
Nevertheless, implementing minimal ikev2 does not solve, for example, NAT-T for 
case 1 so controller should do something anyway.

> 
> 
> For example, most modern ciphers require timely rekeying and must never reuse 
> IV/counters with the same private key.

[Rafa] Why do you imply that IV/counters will be the same with same private 
key? That is not the assumption in case 2 where the controller always generates 
fresh IPsec SAs.

> Synching that across independent hosts is impossible.

[Rafa] I do not see how it is impossible when a controller that have access to 
both NSFs provides that information. If it is not impossible when using IKEv2, 
it should not be impossible for case 2. 

The point is that the result of running IKEv2 is the IPsec SAs in the IPsec 
kernel of both NSFs. In case 2, that state is coming from the controller that 
is performing the key management operations (generate fresh key material, IV, 
etc… per each IPsec SA). The controller has a  connection with both NSFs using, 
for example, NETCONF. Moreover, as I commented , you can read this e-mail 
(https://www.ietf.org/mail-archive/web/i2nsf/current/msg0.html). So there 
is proof that it is working.

Thus, it is more difficult to manage, yes, (in fact, we admit that in our I-D), 
but not impossible. 
In fact, I think it would be worthy if you can provide a concrete example of 
that use case where both NSFs are under the same controller. Maybe we can help 
you to address your concern and explain how the operation would be in that 
specific case you have in mind.

Best Regards and many thanks for your comments.

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

---
Rafael Marin Lopez, PhD
Dept. Information and Communications Engineering (DIIC)
Faculty of Computer Science-University of Murcia
30100 Murcia - Spain
Telf: +3486501 Fax: +34868884151 e-mail: r...@um.es
--






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

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

[Tommy Pauly]

> On Apr 27, 2017, at 7:32 AM, Mirja Kühlewind  wrote:
> 
> See below
> 
> On 27.04.2017 16:27, Eric Rescorla wrote:
>> 
>>"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.
>> 
>> 
>>Hmm... Maybe I don't understand your overall theory here. It seems
>>like having
>>reserved ports for protocols but letting people run them on any port
>>they want
>>to is kind of common practice. See, for instance:
>>https://tools.ietf.org/html/rfc7230#section-2.7.1
>>
>> 
>>"  If the host identifier is provided as an IP address, the origin
>>   server is the listener (if any) on the indicated TCP port at that 
>> IP
>>   address. If host is a registered name, the registered name is an
>>   indirect identifier for use with a name resolution service, such as
>>   DNS, to find an address for that origin server. If the port
>>   subcomponent is empty or not given, TCP port 80 (the reserved port
>>   for WWW services) is the default."
>> 
>> 
>>This doesn't say you can/should use any port you want (it says you can
>>use another port than 80) but you should till avoid to use any other port
>>that runs a different TCP service.
>> 
>> 
>> Well, that may be part of your background assumptions, but the document
>> doesn't say that. It just tells you how to use a different port and is 
>> silent on
>> what port you should use.
>> 
> 
> That's what we have the registry for. The difference is, it's okay to use a 
> random port (instead of one specific reserved one) but this draft explicitly 
> is intended to use other reserved ports.

The only recommended port in the draft is 4500, which is what is reserved in 
the registry. The use of any other port is by configuration only. As Tero and 
others have explained, all IKE connections are made to pre-known pre-configured 
hosts. All the IKE implementations I am aware of allow the useable IKE ports to 
be customized.

I'm fine removing any mention of other specific ports, even in the appendix. 
However, the fact that configurations can choose what ports to use is something 
that needs to be left open. The point of the port registry is to allow devices 
to expect what service will be offered on a given port when they connect. If 
two peers mutually decide to share their own configuration, they can do that.

Thanks,
Tommy

> 
> Mirja
> 
> 
> ___
> 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

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

[Tommy Pauly]

> On Apr 27, 2017, at 6:46 AM, Mirja Kühlewind  wrote:
> 
> One more side comment on the magic number: actually the magic number makes it 
> easy for network operator to identify IKE/IPSec traffic on any port and block 
> all packets that below to a flow that started with this pattern in the first 
> payload packet. So if you really think you need a magic number, you should 
> probably always encrypt it.

The working group determined that the point of the protocol is not to evade any 
possibility for middleboxes to block the traffic, but instead to allow 
connectivity through middle boxes that are essentially 'accidentally' blocking 
IKE/ESP. If an operator wants to block this traffic explicitly, that is fine. 
However, it is very common that networks on public access points will block 
everything by default based on what they consider to be 'web' traffic; they do 
not inspect more deeply.

Thanks,
Tommy

> 
> 
> 
> On 27.04.2017 15:42, Mirja Kühlewind wrote:
>> Hi Ekr, hi all,
>> 
>> (not sure anymore which email best to reply to but I'm using this one now to
>> partly also reply to others).
>> 
>> See below.
>> 
>> On 27.04.2017 14:51, Eric Rescorla wrote:
>>> 
>>> 
>>> On Thu, Apr 27, 2017 at 1:32 AM, Mirja Kühlewind >> > wrote:
>>> 
>>>I do see the problem you have and I understand why you selected the
>>>solution you have but that does contradict quite a bit the idea of the
>>>port registry and I don't think it's a safe and future prove solution.
>>>Even if people use this approach, I'm concern to publish it in an
>>>Standards Track RFC, but I guess that's a discussion the IESG would need
>>>to have.
>>> 
>>> 
>>> Mirja,
>>> 
>>> 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.
>> 
>> 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.
>> 
>> 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? If we could restrict the use of this encapsulation
>> with servers that only are IKE servers (at least for the used port), you
>> would actually not need the magic number anymore. I guess you can still have
>> the magic number if you really want it because that makes it easier to
>> distinguish valid IKE/IPSec traffic from other random traffic that might be
>> send to this port but the other service running on this port (on other
>> servers) does not need to know about the magic number because it is supposed
>> to never see any IKe/IPSec TCP-encapsulated traffic.
>> 
>> Does that make sense?
>> 
>> Mirja
>> 
>> 
>> 
>>> 
>>> -Ekr
>>> 
>>> 
>>> 
>>> 
>>>Mirja
>>> 
>>> 
>>> 
>>>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 

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

[Mirja Kühlewind]

See below

On 27.04.2017 16:27, Eric Rescorla wrote:


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


Hmm... Maybe I don't understand your overall theory here. It seems
like having
reserved ports for protocols but letting people run them on any port
they want
to is kind of common practice. See, for instance:
https://tools.ietf.org/html/rfc7230#section-2.7.1


"  If the host identifier is provided as an IP address, the origin
   server is the listener (if any) on the indicated TCP port at that IP
   address. If host is a registered name, the registered name is an
   indirect identifier for use with a name resolution service, such as
   DNS, to find an address for that origin server. If the port
   subcomponent is empty or not given, TCP port 80 (the reserved port
   for WWW services) is the default."


This doesn't say you can/should use any port you want (it says you can
use another port than 80) but you should till avoid to use any other port
that runs a different TCP service.


Well, that may be part of your background assumptions, but the document
doesn't say that. It just tells you how to use a different port and is silent on
what port you should use.



That's what we have the registry for. The difference is, it's okay to use a 
random port (instead of one specific reserved one) but this draft explicitly 
is intended to use other reserved ports.


Mirja


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

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

[Mirja Kühlewind]

See below.

On 27.04.2017 16:10, Eric Rescorla wrote:



On Thu, Apr 27, 2017 at 6:42 AM, Mirja Kühlewind > wrote:

Hi Ekr, hi all,

(not sure anymore which email best to reply to but I'm using this one now
to partly also reply to others).

See below.

On 27.04.2017 14 :51, Eric Rescorla wrote:



On Thu, Apr 27, 2017 at 1:32 AM, Mirja Kühlewind 
>> wrote:

I do see the problem you have and I understand why you selected the
solution you have but that does contradict quite a bit the idea
of the
port registry and I don't think it's a safe and future prove
solution.
Even if people use this approach, I'm concern to publish it in an
Standards Track RFC, but I guess that's a discussion the IESG
would need
to have.


Mirja,

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.


Hmm... Maybe I don't understand your overall theory here. It seems like having
reserved ports for protocols but letting people run them on any port they want
to is kind of common practice. See, for instance:
https://tools.ietf.org/html/rfc7230#section-2.7.1

"  If the host identifier is provided as an IP address, the origin
   server is the listener (if any) on the indicated TCP port at that IP
   address. If host is a registered name, the registered name is an
   indirect identifier for use with a name resolution service, such as
   DNS, to find an address for that origin server. If the port
   subcomponent is empty or not given, TCP port 80 (the reserved port
   for WWW services) is the default."


This doesn't say you can/should use any port you want (it says you can use 
another port than 80) but you should till avoid to use any other port that 
runs a different TCP service.


Mirja




-Ekr



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.

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? If we could restrict the use of this
encapsulation with servers that only are IKE servers (at least for the
used port), you would actually not need the magic number anymore. I guess
you can still have the magic number if you really want it because that
makes it easier to distinguish valid IKE/IPSec traffic from other random
traffic that might be send to this port but the other service running on
this port (on other servers) does not need to know about the magic number
because it is supposed to never see any IKe/IPSec TCP-encapsulated traffic.

Does that make sense?

Mirja




-Ekr




Mirja



We can soften the references in the appendix to the 

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

[Eric Rescorla]

On Thu, Apr 27, 2017 at 7:21 AM, Mirja Kühlewind 
wrote:

> See below.
>
> On 27.04.2017 16:10, Eric Rescorla wrote:
>
>>
>>
>> On Thu, Apr 27, 2017 at 6:42 AM, Mirja Kühlewind > > wrote:
>>
>> Hi Ekr, hi all,
>>
>> (not sure anymore which email best to reply to but I'm using this one
>> now
>> to partly also reply to others).
>>
>> See below.
>>
>> On 27.04.2017 14 :51, Eric Rescorla wrote:
>>
>>
>>
>> On Thu, Apr 27, 2017 at 1:32 AM, Mirja Kühlewind <
>> i...@kuehlewind.net
>> 
>> >> wrote:
>>
>> I do see the problem you have and I understand why you
>> selected the
>> solution you have but that does contradict quite a bit the
>> idea
>> of the
>> port registry and I don't think it's a safe and future prove
>> solution.
>> Even if people use this approach, I'm concern to publish it
>> in an
>> Standards Track RFC, but I guess that's a discussion the IESG
>> would need
>> to have.
>>
>>
>> Mirja,
>>
>> 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.
>>
>>
>> Hmm... Maybe I don't understand your overall theory here. It seems like
>> having
>> reserved ports for protocols but letting people run them on any port they
>> want
>> to is kind of common practice. See, for instance:
>> https://tools.ietf.org/html/rfc7230#section-2.7.1
>>
>> "  If the host identifier is provided as an IP address, the origin
>>server is the listener (if any) on the indicated TCP port at that IP
>>address. If host is a registered name, the registered name is an
>>indirect identifier for use with a name resolution service, such as
>>DNS, to find an address for that origin server. If the port
>>subcomponent is empty or not given, TCP port 80 (the reserved port
>>for WWW services) is the default."
>>
>
> This doesn't say you can/should use any port you want (it says you can use
> another port than 80) but you should till avoid to use any other port that
> runs a different TCP service.
>

Well, that may be part of your background assumptions, but the document
doesn't say that. It just tells you how to use a different port and is
silent on
what port you should use.

-Ekr


> Mirja
>
>
>
>> -Ekr
>>
>>
>>
>> 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.
>>
>> 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? If we could restrict the use of this
>> encapsulation with servers that only are IKE servers (at least for 

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

[Tero Kivinen]

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

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.

Another issue might be that the SGW terminating the TCP 443
connection, might also support some proprietary TLS VPN implementation
and differntiating from that is also something I can see that vendors
might want to do.

So I do not know if anybody is really do it now, but I can see reasons
why people might want to multiplex the proprietary things they are now
running on those ports 500/4500/443 with the standard we are defining
here.

> If we could restrict the use of this encapsulation 
> with servers that only are IKE servers (at least for the used port), you 
> would actually not need the magic number anymore. I guess you can 

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

[Eric Rescorla]

On Thu, Apr 27, 2017 at 6:42 AM, Mirja Kühlewind 
wrote:

> Hi Ekr, hi all,
>
> (not sure anymore which email best to reply to but I'm using this one now
> to partly also reply to others).
>
> See below.
>
> On 27.04.2017 14:51, Eric Rescorla wrote:
>
>>
>>
>> On Thu, Apr 27, 2017 at 1:32 AM, Mirja Kühlewind > > wrote:
>>
>> I do see the problem you have and I understand why you selected the
>> solution you have but that does contradict quite a bit the idea of the
>> port registry and I don't think it's a safe and future prove solution.
>> Even if people use this approach, I'm concern to publish it in an
>> Standards Track RFC, but I guess that's a discussion the IESG would
>> need
>> to have.
>>
>>
>> Mirja,
>>
>> 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.
>

Hmm... Maybe I don't understand your overall theory here. It seems like
having
reserved ports for protocols but letting people run them on any port they
want
to is kind of common practice. See, for instance:
https://tools.ietf.org/html/rfc7230#section-2.7.1

"  If the host identifier is provided as an IP address, the origin
   server is the listener (if any) on the indicated TCP port at that IP
   address. If host is a registered name, the registered name is an
   indirect identifier for use with a name resolution service, such as
   DNS, to find an address for that origin server. If the port
   subcomponent is empty or not given, TCP port 80 (the reserved port
   for WWW services) is the default."

-Ekr



> 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.
>
> 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? If we could restrict the use of this
> encapsulation with servers that only are IKE servers (at least for the used
> port), you would actually not need the magic number anymore. I guess you
> can still have the magic number if you really want it because that makes it
> easier to distinguish valid IKE/IPSec traffic from other random traffic
> that might be send to this port but the other service running on this port
> (on other servers) does not need to know about the magic number because it
> is supposed to never see any IKe/IPSec TCP-encapsulated traffic.
>
> Does that make sense?
>
> Mirja
>
>
>
>
>> -Ekr
>>
>>
>>
>>
>> Mirja
>>
>>
>>
>> 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:
>>

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

[Mirja Kühlewind]

Yes, just saying...

On 27.04.2017 15:50, Eric Rescorla wrote:



On Thu, Apr 27, 2017 at 6:46 AM, Mirja Kühlewind > wrote:

One more side comment on the magic number: actually the magic number
makes it easy for network operator to identify IKE/IPSec traffic on any
port and block all packets that below to a flow that started with this
pattern in the first payload packet. So if you really think you need a
magic number, you should probably always encrypt it.


My impression was that the point of this was not to evade future operators
who are trying to block IKE, but merely to deal with the problem of
over-aggressive
middleboxes which currently block IKE, mostly accidentally. Certainly that's how
we think of things over in WebRTC land.

-Ekr


On 27.04.2017 15 :42, Mirja Kühlewind wrote:

Hi Ekr, hi all,

(not sure anymore which email best to reply to but I'm using this one
now to
partly also reply to others).

See below.

On 27.04.2017 14 :51, Eric Rescorla wrote:



On Thu, Apr 27, 2017 at 1:32 AM, Mirja Kühlewind

>> wrote:

I do see the problem you have and I understand why you
selected the
solution you have but that does contradict quite a bit the
idea of the
port registry and I don't think it's a safe and future prove
solution.
Even if people use this approach, I'm concern to publish it in 
an
Standards Track RFC, but I guess that's a discussion the IESG
would need
to have.


Mirja,

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.

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.

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? If we could restrict the use of this
encapsulation
with servers that only are IKE servers (at least for the used port), you
would actually not need the magic number anymore. I guess you can
still have
the magic number if you really want it because that makes it easier to
distinguish valid IKE/IPSec traffic from other random traffic that
might be
send to this port but the other service running on this port (on other
servers) does not need to know about the magic 

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

[Spencer Dawkins at IETF]

Tero,

Top-posting, because I'm only saying "thank you, that's very helpful".

Spencer

On Thu, Apr 27, 2017 at 8:50 AM, Tero Kivinen  wrote:

> Spencer Dawkins at IETF writes:
> > The reason optional ports in URIs work, is that someone handed you a URI
> with
> > that port number who has some reason to believe that the port number is
> OK to
> > use with the host included in the URI.
> >
> > Is that a reasonable assumption about the way IPsec and IKE over TCP
> will be
> > deployed? That no Initiator would assume that another host is an IKE
> > Responder, without being configured to use that host?
>
> I have been using following matrix to understand the IETF security
> protocols:
>
> +-+---+--+
> | | "Kernel" mode | Application mode |
> +-+---+--+
> | Pre-configuration   | IPsec | Secure Shell |
> | required|   |  |
> +-+---+--+
> | No per host | HIP   | SSL/TLS  |
> | pre configuration   | / |  |
> | needed /| TCPINC|  |
> | opportunistic   |   |  |
> +-+---+--+
>
> Kernel mode means it is implemented inside the operating system kernel
> or libraries, and Application mode means it is part of the application
> level implementation.
>
> Pre-configuration required means that both ends needs to be
> pre-configured to accept the connection. I.e., there is no point of
> trying to use ssh to connect host kivinen.iki.fi unless you have
> account and some method of authentication token for that host. Same
> with IPsec, you cannot assume that other end talks IPsec and allows
> you to connect unless you have pre-configured both ends to support it.
>
> Even when using opportunistic IPsec this is mostly same, there is no
> point of even trying to use opportunistic IPsec to www.google.com, and
> assume it would work. It might be that at some day we are there, and
> we have opportunistic IPsec installed in every single host, but we are
> not there now, and main use of IPsec is with pre-configuration.
>
> With HIP and TCPINC you always assume that you simply connect the
> other end and you do not need per host configuration. The connection
> either works or not, and if not you fall back to TCP (TCPINC), or just
> fail (with HIP adding configuration might help).
>
> With TLS you can just assume that other end allows you to connect if
> it supports TLS at all, and this is because everybody is
> "pre-configured" with same trusted anchor list, but there is no need
> for per-host configuration.
>
> So short answer to your question is: IPsec do require
> pre-configuration, so if configuration says that IP address x.y.z.0
> talks IPsec over TCP on port 1234, then you do that. If there is no
> configuration then you usually just fail, as you do not know what
> authentication credentials you are supposed to use.
> --
> kivi...@iki.fi
>
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Mirja Kühlewind]

One more side comment on the magic number: actually the magic number makes it 
easy for network operator to identify IKE/IPSec traffic on any port and block 
all packets that below to a flow that started with this pattern in the first 
payload packet. So if you really think you need a magic number, you should 
probably always encrypt it.




On 27.04.2017 15:42, Mirja Kühlewind wrote:

Hi Ekr, hi all,

(not sure anymore which email best to reply to but I'm using this one now to
partly also reply to others).

See below.

On 27.04.2017 14:51, Eric Rescorla wrote:



On Thu, Apr 27, 2017 at 1:32 AM, Mirja Kühlewind > wrote:

I do see the problem you have and I understand why you selected the
solution you have but that does contradict quite a bit the idea of the
port registry and I don't think it's a safe and future prove solution.
Even if people use this approach, I'm concern to publish it in an
Standards Track RFC, but I guess that's a discussion the IESG would need
to have.


Mirja,

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.

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.

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? If we could restrict the use of this encapsulation
with servers that only are IKE servers (at least for the used port), you
would actually not need the magic number anymore. I guess you can still have
the magic number if you really want it because that makes it easier to
distinguish valid IKE/IPSec traffic from other random traffic that might be
send to this port but the other service running on this port (on other
servers) does not need to know about the magic number because it is supposed
to never see any IKe/IPSec TCP-encapsulated traffic.

Does that make sense?

Mirja





-Ekr




Mirja



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 

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

[Tero Kivinen]

Spencer Dawkins at IETF writes:
> The reason optional ports in URIs work, is that someone handed you a URI with
> that port number who has some reason to believe that the port number is OK to
> use with the host included in the URI.
> 
> Is that a reasonable assumption about the way IPsec and IKE over TCP will be
> deployed? That no Initiator would assume that another host is an IKE
> Responder, without being configured to use that host?

I have been using following matrix to understand the IETF security
protocols:

+-+---+--+
| | "Kernel" mode | Application mode |
+-+---+--+
| Pre-configuration   | IPsec | Secure Shell |
| required|   |  |
+-+---+--+
| No per host | HIP   | SSL/TLS  |
| pre configuration   | / |  |
| needed /| TCPINC|  |
| opportunistic   |   |  |
+-+---+--+

Kernel mode means it is implemented inside the operating system kernel
or libraries, and Application mode means it is part of the application
level implementation.

Pre-configuration required means that both ends needs to be
pre-configured to accept the connection. I.e., there is no point of
trying to use ssh to connect host kivinen.iki.fi unless you have
account and some method of authentication token for that host. Same
with IPsec, you cannot assume that other end talks IPsec and allows
you to connect unless you have pre-configured both ends to support it.

Even when using opportunistic IPsec this is mostly same, there is no
point of even trying to use opportunistic IPsec to www.google.com, and
assume it would work. It might be that at some day we are there, and
we have opportunistic IPsec installed in every single host, but we are
not there now, and main use of IPsec is with pre-configuration.

With HIP and TCPINC you always assume that you simply connect the
other end and you do not need per host configuration. The connection
either works or not, and if not you fall back to TCP (TCPINC), or just
fail (with HIP adding configuration might help).

With TLS you can just assume that other end allows you to connect if
it supports TLS at all, and this is because everybody is
"pre-configured" with same trusted anchor list, but there is no need
for per-host configuration.

So short answer to your question is: IPsec do require
pre-configuration, so if configuration says that IP address x.y.z.0
talks IPsec over TCP on port 1234, then you do that. If there is no
configuration then you usually just fail, as you do not know what
authentication credentials you are supposed to use.
-- 
kivi...@iki.fi

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

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

[Eric Rescorla]

On Thu, Apr 27, 2017 at 6:46 AM, Mirja Kühlewind 
wrote:

> One more side comment on the magic number: actually the magic number makes
> it easy for network operator to identify IKE/IPSec traffic on any port and
> block all packets that below to a flow that started with this pattern in
> the first payload packet. So if you really think you need a magic number,
> you should probably always encrypt it.
>
>
My impression was that the point of this was not to evade future operators
who are trying to block IKE, but merely to deal with the problem of
over-aggressive
middleboxes which currently block IKE, mostly accidentally. Certainly
that's how
we think of things over in WebRTC land.

-Ekr


> On 27.04.2017 15:42, Mirja Kühlewind wrote:
>
>> Hi Ekr, hi all,
>>
>> (not sure anymore which email best to reply to but I'm using this one now
>> to
>> partly also reply to others).
>>
>> See below.
>>
>> On 27.04.2017 14:51, Eric Rescorla wrote:
>>
>>>
>>>
>>> On Thu, Apr 27, 2017 at 1:32 AM, Mirja Kühlewind >> > wrote:
>>>
>>> I do see the problem you have and I understand why you selected the
>>> solution you have but that does contradict quite a bit the idea of
>>> the
>>> port registry and I don't think it's a safe and future prove
>>> solution.
>>> Even if people use this approach, I'm concern to publish it in an
>>> Standards Track RFC, but I guess that's a discussion the IESG would
>>> need
>>> to have.
>>>
>>>
>>> Mirja,
>>>
>>> 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.
>>
>> 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.
>>
>> 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? If we could restrict the use of this
>> encapsulation
>> with servers that only are IKE servers (at least for the used port), you
>> would actually not need the magic number anymore. I guess you can still
>> have
>> the magic number if you really want it because that makes it easier to
>> distinguish valid IKE/IPSec traffic from other random traffic that might
>> be
>> send to this port but the other service running on this port (on other
>> servers) does not need to know about the magic number because it is
>> supposed
>> to never see any IKe/IPSec TCP-encapsulated traffic.
>>
>> Does that make sense?
>>
>> Mirja
>>
>>
>>
>>
>>> -Ekr
>>>
>>>
>>>
>>>
>>> Mirja
>>>
>>>
>>>
>>> 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 

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

[Mirja Kühlewind]

Hi Ekr, hi all,

(not sure anymore which email best to reply to but I'm using this one now to 
partly also reply to others).


See below.

On 27.04.2017 14:51, Eric Rescorla wrote:



On Thu, Apr 27, 2017 at 1:32 AM, Mirja Kühlewind > wrote:

I do see the problem you have and I understand why you selected the
solution you have but that does contradict quite a bit the idea of the
port registry and I don't think it's a safe and future prove solution.
Even if people use this approach, I'm concern to publish it in an
Standards Track RFC, but I guess that's a discussion the IESG would need
to have.


Mirja,

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.


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.


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? If we could restrict the use of this encapsulation 
with servers that only are IKE servers (at least for the used port), you 
would actually not need the magic number anymore. I guess you can still have 
the magic number if you really want it because that makes it easier to 
distinguish valid IKE/IPSec traffic from other random traffic that might be 
send to this port but the other service running on this port (on other 
servers) does not need to know about the magic number because it is supposed 
to never see any IKe/IPSec TCP-encapsulated traffic.


Does that make sense?

Mirja





-Ekr




Mirja



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 

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

[Eric Rescorla]

On Thu, Apr 27, 2017 at 6:00 AM, Eric Rescorla  wrote:

>
>
> On Wed, Apr 26, 2017 at 2:29 PM, Tommy Pauly  wrote:
>
>>
>> On Apr 26, 2017, at 12:51 PM, Eric Rescorla  wrote:
>>
>> AFAICT there are two separate issues:
>>
>> - The use of 4500, which, as Tero says, we can just update the registry
>> to point to this document for.
>> - The use of 443, which seems more complicated
>>
>> WRT 443, I would assert the following facts:
>>
>> - It's not awesome that people use 443 (though understandable because of
>> overly-aggressive firewalls)
>> - People aren't going to stop using 443 (because it goes through NATs
>> well)
>>
>> Generally, I think it's more useful for documents to reflect reality,
>> even if we don't like that reality,
>> and 443 only appears in the appendix, so that seems fairly innocuous to
>> me. Perhaps we can
>> leave the 443 in the appendix with some note like:
>>
>> "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"
>>
>>
>> What would people think about that?
>>
>>
>> That sounds good to me. I think we may want to mention that the Stream
>> Prefix is used to distinguish from any other protocols running on port
>> 4500, etc, not really specifically to 443.
>>
>
> Good point.
>
>
> Tommy, Tero, the stream prefix doesn't seem totally ideal. Would there be
>> wiggle room
>> to specify ALPN here? Or maybe a longer prefix?
>>
>>
>> The document's text regarding ALPN is in section 4:
>>
>> "Although some framing protocols do support negotiating inner protocols,
>> the stream prefix should always be used in order for implementations to be
>> as generic as possible and not rely on other framing protocols on top of
>> TCP."
>>
>> The idea is that we don't want to use TLS as a wrapper whenever possible.
>> An implementation on an IKE server may be behind a proxy or another process
>> that's terminating the TLS or raw TCP, and passing the inner stream along.
>> In that case, we wanted a standard way to put IKE and ESP in a stream, not
>> relying on an outer protocol's details.
>>
>
> I get that, but it is a bit unfortunate to be relying on this inband
> signaling.
>

Replying to myself (and in light of Benoit's comments).

The advantage of ALPN is that it would let outgoing firewall devices do
some kind
of filtering even for the TLS traffic (which of course will not be possible
if you
use non-NULL ciphers which you will have to for 1.3).

-Ekr


>
>
>> I'm perfectly open to using another prefix value; if you have a
>> suggestion for a longer value, that would be great!
>>
>
> I think I'd probably ask MT or mnot, but my instinct would be to use some
> randomly chosen string
> that started with IKETCP. E.g., IKETCP + 8ish random bytes. This just
> reduces the chance of
> any kind of accidental collision. I don't think it's a dealbreaker.
>
> -Ekr
>
>
>
>
>> Thanks,
>> Tommy
>>
>>
>> -Ekr
>>
>>
>> On Wed, Apr 26, 2017 at 3:46 AM, Tero Kivinen  wrote:
>>
>>> Tommy Pauly writes:
>>> > > 
>>> --
>>> > > 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.
>>>
>>> I already explained this in long email to the Joe and Paul, but
>>> noticed that those emails did not go to to the IESG, so this is mostly
>>> cut & paste of my previous email. This does not cover anything about
>>> using any other ports, but covers the case about the IANA allocations
>>> for TCP/4500 and UPD/4500.
>>>
>>> --
>>> Paul Wouters writes:
>>> > On Tue, 25 Apr 2017, Joe Touch wrote:
>>> > > Every bit pattern, including those using magic numbers, is already
>>> > > owned and under the control of each assigned port. It 

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

[Eric Rescorla]

On Wed, Apr 26, 2017 at 2:29 PM, Tommy Pauly  wrote:

>
> On Apr 26, 2017, at 12:51 PM, Eric Rescorla  wrote:
>
> AFAICT there are two separate issues:
>
> - The use of 4500, which, as Tero says, we can just update the registry to
> point to this document for.
> - The use of 443, which seems more complicated
>
> WRT 443, I would assert the following facts:
>
> - It's not awesome that people use 443 (though understandable because of
> overly-aggressive firewalls)
> - People aren't going to stop using 443 (because it goes through NATs well)
>
> Generally, I think it's more useful for documents to reflect reality, even
> if we don't like that reality,
> and 443 only appears in the appendix, so that seems fairly innocuous to
> me. Perhaps we can
> leave the 443 in the appendix with some note like:
>
> "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"
>
>
> What would people think about that?
>
>
> That sounds good to me. I think we may want to mention that the Stream
> Prefix is used to distinguish from any other protocols running on port
> 4500, etc, not really specifically to 443.
>

Good point.


Tommy, Tero, the stream prefix doesn't seem totally ideal. Would there be
> wiggle room
> to specify ALPN here? Or maybe a longer prefix?
>
>
> The document's text regarding ALPN is in section 4:
>
> "Although some framing protocols do support negotiating inner protocols,
> the stream prefix should always be used in order for implementations to be
> as generic as possible and not rely on other framing protocols on top of
> TCP."
>
> The idea is that we don't want to use TLS as a wrapper whenever possible.
> An implementation on an IKE server may be behind a proxy or another process
> that's terminating the TLS or raw TCP, and passing the inner stream along.
> In that case, we wanted a standard way to put IKE and ESP in a stream, not
> relying on an outer protocol's details.
>

I get that, but it is a bit unfortunate to be relying on this inband
signaling.



> I'm perfectly open to using another prefix value; if you have a suggestion
> for a longer value, that would be great!
>

I think I'd probably ask MT or mnot, but my instinct would be to use some
randomly chosen string
that started with IKETCP. E.g., IKETCP + 8ish random bytes. This just
reduces the chance of
any kind of accidental collision. I don't think it's a dealbreaker.

-Ekr




> Thanks,
> Tommy
>
>
> -Ekr
>
>
> On Wed, Apr 26, 2017 at 3:46 AM, Tero Kivinen  wrote:
>
>> Tommy Pauly writes:
>> > > 
>> --
>> > > 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.
>>
>> I already explained this in long email to the Joe and Paul, but
>> noticed that those emails did not go to to the IESG, so this is mostly
>> cut & paste of my previous email. This does not cover anything about
>> using any other ports, but covers the case about the IANA allocations
>> for TCP/4500 and UPD/4500.
>>
>> --
>> Paul Wouters writes:
>> > On Tue, 25 Apr 2017, Joe Touch wrote:
>> > > 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
>>
>> Not really. It does not update RFC3947 as it does not change the
>> 

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

[Eric Rescorla]

On Thu, Apr 27, 2017 at 1:32 AM, Mirja Kühlewind 
wrote:
>
> I do see the problem you have and I understand why you selected the
> solution you have but that does contradict quite a bit the idea of the port
> registry and I don't think it's a safe and future prove solution. Even if
> people use this approach, I'm concern to publish it in an Standards Track
> RFC, but I guess that's a discussion the IESG would need to have.


Mirja,

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?

-Ekr


>
>
> Mirja
>
>
>
>> 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 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
>>>
>>
>>
> ___
> IPsec mailing list
> IPsec@ietf.org
> 

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

[Tero Kivinen]

Eric Rescorla writes:
> AFAICT there are two separate issues:
> 
> - The use of 4500, which, as Tero says, we can just update the registry to
> point to this document for.
> - The use of 443, which seems more complicated

Yes. 

> WRT 443, I would assert the following facts:
> 
> - It's not awesome that people use 443 (though understandable because of
> overly-aggressive firewalls)
> - People aren't going to stop using 443 (because it goes through NATs well)

Especially as this has already been specified by the 3gpp TS.24.302
[1], [2].

One of the reasons we are doing this is that 3GPP defined how to run
IPsec over TCP, and they decided to use port 443 and TLS framing for
that (or HTTP proxy supporting HTTPCONNECT).

I.e., they specified firewall traversal that will make TCP connection
to port 443 of the ePDG address, and do normal TLS handshake over
that, and then run TCP stream over that which will have IKEv2 and ESP
frames similar what is defined here.

When IPsec WG decided this is something that should be standardized
for general use, we took that but we did not want to limit it to port
443 and TLS framing only, so we decided that we would define it mostly
on port TCP/4500 without TLS.

The original draft had text about the TLS in main body, but as it was
moved to Appendix during the working group process.

So regardless what we do here 3GPP will be running IPsec over TLS over
TCP port 443 (i.e., IPsec, not HTTP inside the TLS).

To be aligned with them we did for example change the length field
before the messages to be 16-bit instead of original 32-bits. On the
other hand we did add IKETCP stream prefix there, as that allows us to
detect this is IETF version of the IPsec over TCP, not some
proprietary or 3gpp method done before (just in case there are other
differences we did not spot). 

[1] 
https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=1073
[2] http://www.3gpp.org/ftp//Specs/archive/24_series/24.302/24302-e30.zip

> Generally, I think it's more useful for documents to reflect
> reality, even if we don't like that reality, and 443 only appears in
> the appendix, so that seems fairly innocuous to me. Perhaps we can
> leave the 443 in the appendix with some note like:

This was the reason why WG originally wanted to move it to Appendix,
and not remove it completely. 

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

I think that text would be fine for me at least (but I am not author
of this draft). 

> What would people think about that?
> 
> Tommy, Tero, the stream prefix doesn't seem totally ideal. Would
> there be wiggle room to specify ALPN here? Or maybe a longer prefix?

The stream prefix is done also on the port 4500 or any other
configured port, and those will not use TLS. Only the port 443 (or
other configured ports defined to use TLS) will use TLS. Also the TLS
wrapper before the IPsec / IKE might be completely sepearate module,
and transferring things from there to IPsec module might be hard.

The stream prefix is also inside the TLS wrapping (see B.1. example),
i.e., it is the first bytes that come from the stream coming out from
the TLS after the TLS handshake is finished. So for the IPsec module,
it does not need to know whether there was TLS warpping around the TCP
stream or not, it will get stream of octets starting with "IKETCP",
and then followed by IKE or ESP packets.

Also, note, that responder might use the fact that when new connection
comes in and it starts with "IKETCP" as indication that there is no
TLS wrapping around the frames, and give them directly to IPsec
module. If there is something else, then it might try to do TLS
handshake and if that successed, then check if inside the TLS there is
"IKETCP" stream prefix and if so, then give that data to the IPsec
module. This is something they could do on any port they are
configured to listen, not only port 4500 or 443. Or it could be they
are configured so that port 4500 is always without TLS framing, port
443 is always with TLS framing, and other configured ports have
automatic TLS detection and processing enabled
-- 
kivi...@iki.fi

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

[IPsec] Benoit Claise's No Objection on draft-ietf-ipsecme-tcp-encaps-09: (with COMMENT)

[Benoit Claise]

Benoit Claise has entered the following ballot position for
draft-ietf-ipsecme-tcp-encaps-09: No Objection

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

Just sharing some random thoughts. No action is needed here. 

   Most implementations should use TCP
   Encapsulation only on networks where negotiation over UDP has been
   attempted without receiving responses from the peer, or if a network
   is known to not support UDP.

On one side, some companies deny IKE/IPSEC on purpose.
In the future, they will just block port 4500.

   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.

Well, if any port can be used, that becomes difficult.
On the other hand, just is like any tunneling mechanisms, which exist for
some time already.

QoS within TCP will be a real operational issues, as inner to outer ToS
mapping is not possible.


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

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

[Spencer Dawkins at IETF]

Not my discuss, but since I'm also supposed to worry about ports :-)

On Thu, Apr 27, 2017 at 3:32 AM, Mirja Kühlewind 
wrote:

> Hi Tommy,
>
> please see below, only on the first point for now.
>
> On 26.04.2017 05:28, Tommy Pauly wrote:
>
>>
>>
>> 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/stat
>>> ement/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.
>>
>
> So at least section 11 talks about port 80 as well. It doesn't explicitly
> recommend to use it, but because it's discussed there I would say that this
> is implicitly the intention:
>
> "A network device that monitors up to the application layer will
>commonly expect to see HTTP traffic within a TCP socket running over
>port 80, if non-HTTP traffic is seen (such as TCP encapsulated IKE),
>this could be dropped by the security device."
>

I understand Mirja's point, and I understand why the draft doesn't tie the
protocol to one assigned port.

>
> Further it's clear that the whole intention on the existence of section 4
> is that you want to (mis)use ports that have been assigned for other
> services and are for that reason potentially not blocked.
>
> The (processing) problem here is that even if the bit pattern in section 4
> is currently not used and unlikely to ever be used by the protocol that is
> officially assigned to the port, there is nothing that excludes a future
> protocol spec to use these bits (and there is also nothing that makes
> designer of these protocols aware that these bits are already in use by a
> different protocol on the same port). So the minimum you basically would
> need to do is to update all RFCs for protocols on ports that you may want
> to use (and probably also the IANA registry for these ports to add a
> refernce to this document) and say that it is not possible to use this bit
> patter for the protocol itself and all future version of it. Of course you
> probably would need to involve those working groups that maintain these
> protocols and I also not sure how happy those groups would be about such an
> update.
>

What I'm thinking, is that this isn't a problem we can solve, draft by
draft.

Assuming that https://datatracker.ietf.org/doc/rfc3986/referencedby/ is a
reasonable proxy, the datatracker returns 775 documents that reference the
RFC that defines the URI scheme, which includes
https://tools.ietf.org/html/rfc3986#section-3.2.3, allowing the application
to specify a port which (of course) could be assigned to another protocol
in
https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.txt
.

That's a worst-case scenario, of course (some RFCs weren't deployed, some
are probably obsoleted by other RFCs, etc.), but I'm betting the number of
protocols with the same issue as HTTP(S) has here is somewhere in the
hundreds.

>
> I personally think that that is not a nice solution and if you e.g. want
> to use port 80 for IKE, you would need to define an IKE variant over
> HTTP/TCP. That doesn't sound great and I'm not sure if that a solution
> anybody would like to implement.
>
> I do see the problem you have and I understand why you selected the
> solution you have but that does contradict quite a bit the idea of the port
> registry and I don't think it's a safe and future prove solution. Even if
> people 

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

[Tero Kivinen]

Ben Campbell writes:
> 
> > On Apr 26, 2017, at 6:06 AM, Tero Kivinen  wrote:
> > 
> > Ben Campbell writes:
> >> --
> >> COMMENT:
> >> --
> >> 
> >> Substantive Comments:
> >> 
> >> -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.)
> > 
> > If we ever want to run other protocols there, we still have 255
> > reserved values we can use as Non-ESP marker. The reason the
> > 0x is selected as Non-ESP marker in the UDP encapsulation (and
> > here) is because first four octets of the ESP packet are SPI, and SPI
> > MUST NOT be zero. Also numbers from 1 to 255 are "are reserved by the
> > Internet Assigned Numbers Authority (IANA) for future use" in the
> > RFC4303.
> > 
> > So if we need to run something else than IKE and ESP over that tunnel
> > we just reserve one of the other reserved IANA numbers for it and use
> > it as protocol marker for this new protocol. 
> 
> Ah, I didn’t realize 1-255 were reserved. It might be worth a
> mention that if future protocols are added, their prefixes must be
> registered with IANA. (I note that 2 are registered already.)

I do not think it belongs to this document. This is not actually using
reserved SPIs, but I think it should be enough to see that there is a
way to extend this, but as we do not see the need for extension now,
we do not need to think how we are going to do it. There are other
ways of doing that extension also and everything depends what we
really want to do.

Trying to guess things now is not really useful.

> Am I correct to assume the draft did not also add a prefix for ESP
> is due to performance reasons? Doing so would completely avoid any
> possible collisions between the prefix value and the SPI.

Actually RFC3947/3948 original invented this method, and the reason we
do not add prefix is to save 4 or 8 octets on every single ESP packet.
The ESP header needs to be alinged to 4 or 8 octet boundary thus
minimum overhead would be 4 or 8 octets (see RFC5840 for example,
i.e., WESP adds extra header before ESP).

There is no possibility with collisions with ESP, as ESP specifies
that SPI zero is always reserved, and MUST NOT ever appear on the
wire. Thus ESP packet with SPI of zero is invalid. As IKE packets are
much less frequent than ESP packets (with ratio of million or billion
to 1), it does not matter that we add some extra overhead to them.
Also IKE payload does not need to be aligned so we can go with just 4
octets of overhead, and does not need to care about the IPv4 vs IPv6
alignment requirements.

> Got it. I propose the following:
> 
> OLD:
> The SPI field in the ESP header MUST NOT be a zero value.”
> NEW:
> [RFC4303] forbids a value of zero in the SPI field.

That is good change, I would recommend that authors do that change. 
-- 
kivi...@iki.fi

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

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

[Mirja Kühlewind]

Hi Tommy,

please see below, only on the first point for now.

On 26.04.2017 05:28, Tommy Pauly wrote:




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.


So at least section 11 talks about port 80 as well. It doesn't explicitly 
recommend to use it, but because it's discussed there I would say that this 
is implicitly the intention:


"A network device that monitors up to the application layer will
   commonly expect to see HTTP traffic within a TCP socket running over
   port 80, if non-HTTP traffic is seen (such as TCP encapsulated IKE),
   this could be dropped by the security device."

Further it's clear that the whole intention on the existence of section 4 is 
that you want to (mis)use ports that have been assigned for other services 
and are for that reason potentially not blocked.


The (processing) problem here is that even if the bit pattern in section 4 is 
currently not used and unlikely to ever be used by the protocol that is 
officially assigned to the port, there is nothing that excludes a future 
protocol spec to use these bits (and there is also nothing that makes 
designer of these protocols aware that these bits are already in use by a 
different protocol on the same port). So the minimum you basically would need 
to do is to update all RFCs for protocols on ports that you may want to use 
(and probably also the IANA registry for these ports to add a refernce to 
this document) and say that it is not possible to use this bit patter for the 
protocol itself and all future version of it. Of course you probably would 
need to involve those working groups that maintain these protocols and I also 
not sure how happy those groups would be about such an update.


I personally think that that is not a nice solution and if you e.g. want to 
use port 80 for IKE, you would need to define an IKE variant over HTTP/TCP. 
That doesn't sound great and I'm not sure if that a solution anybody would 
like to implement.


I do see the problem you have and I understand why you selected the solution 
you have but that does contradict quite a bit the idea of the port registry 
and I don't think it's a safe and future prove solution. Even if people use 
this approach, I'm concern to publish it in an Standards Track RFC, but I 
guess that's a discussion the IESG would need to have.


Mirja



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