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

[Spencer Dawkins at IETF]

On Apr 26, 2017 16:23, "Tommy Pauly"  wrote:



On Apr 26, 2017, at 1:08 PM, Ben Campbell  wrote:


On Apr 26, 2017, at 2:58 PM, Spencer Dawkins at IETF <
spencerdawkins.i...@gmail.com> wrote:

Hi, Ben and Tommy,

On Wed, Apr 26, 2017 at 1:36 PM, Ben Campbell  wrote:

On Apr 26, 2017, at 12:50 PM, Tommy Pauly  wrote:

Hi Ben,

Thanks for the comments! Your point about the line in Section 6 not making
sense is definitely a good point. How about this text (changes in bold):

If a TCP connection is being used to resume a previous IKE session,
  the TCP Responder can recognize the session using either the IKE SPI
  from an encapsulated IKE message or the ESP SPI from an encapsulated
  ESP message.  If the session had been fully established previously,
  it is suggested that the TCP Originator send an UPDATE_SA_ADDRESSES
  message if MOBIKE is supported, or an INFORMATIONAL message (a
  keepalive) otherwise.  [The TCP Responder MUST NOT accept any messages
  for the existing IKE session on new an incoming connection unless that
connection
  begins with the stream prefix. If either the TCP Originator or TCP
Responder
  cannot parse valid IKE or ESP messages on a TCP encapsulation connection
  that was started with a valid stream prefix, it MUST close the TCP
connection.]
  If there is instead a syntax issue within an IKE
  message, an implementation MUST send the INVALID_SYNTAX notify
  payload and tear down the IKE SA as usual, rather than tearing down
  the TCP connection directly.

Thanks,
Tommy


That looks good to me. I will clear, with the assumption this or similar
edits will make it into the draft.

Does

The TCP Responder MUST NOT accept any messages
  for the existing IKE session on new an incoming connection unless that
connection
  begins with the stream prefix.

parse for you guys? I get stuck at "on new an incoming”.



I’m guessing that’s an edit-o from. Maybe it should be “on a new incoming”?


Yes, I meant "on a new incoming connection". Sorry!


Thanks for clarifying. I thought I was experiencing telechat blindness ;-)

Spencer


Thanks,
Tommy



Spencer


Thanks!

Ben.



On Apr 26, 2017, at 8:35 AM, Ben Campbell  wrote:

By the way, the DISCUSS vs COMMENT framing has gotten lost from the thread.
Only the first point was part of the DISCUSS, the rest are non-binding
comments. And I think the DISCUSS point is moving in the right direction,
pending a text proposal.

Thanks!

Ben.

On Apr 26, 2017, at 8:57 AM, Kathleen Moriarty <
kathleen.moriarty.i...@gmail.com> wrote:

On Tue, Apr 25, 2017 at 11:54 PM, Ben Campbell  wrote:


On Apr 25, 2017, at 9:38 PM, Kathleen Moriarty <
kathleen.moriarty.i...@gmail.com> wrote:

Thanks for the quick response Paul, a few questions...

On Tue, Apr 25, 2017 at 10:18 PM, Paul Wouters  wrote:

On Tue, 25 Apr 2017, Kathleen Moriarty wrote:

IIUC, the entire point of having the stream prefix is to allow the TCP
responder to demux between this protocol, and some other protocol that
would normally run on that port. Saying it MUST close the TCP session
seems to completely remove that value. I assume people meant to allow the
respondent to delegate a stream out to some other protocol handler if the
prefix is not present?


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



Vendors tend to run TLS on the IKE/IPsec machine, either to offer one of
the other kinds of SSL VPNs or as the administration interface or
user interface.


OK, sounds like I didn't help here, so the editors should propose text
to address this gap.


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



-- 2nd to last paragraph: "This document leaves the selection of TCP
ports up to implementations."
I suspect "configurable local policy" would make more sense. Leaving it
up to "implementations" leaves open the chance of different
implementations making non-intersecting port choices, which doesn't help
interoperability.



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



I am pretty sure what is meant is "configuration" and not "implementation".


Is that in response to me being wrong in my assumption or the draft
should say configuration (I think it's the latter, but important to
check)?


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

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

[Tommy Pauly]

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

> 
> 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'm perfectly open to using another prefix value; if you have a suggestion for 
a longer value, that would be great!

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
> obsoleted protocol defined in the RFC3947. It does define way to
> extend things in IKE in similar way than RFC3948 (UDPENCAPS) does. On
> the other hand RFC3947 should have been obsoleted when we obsoleted
> IKEv1, as that document only defines how to do IKEv1 NAT traversal
> negotiation, and the IKEv2 NAT traversal negotation is described in
> main IKEv2 RFC (RFC7296).
> 
> > It's a little weird. 3947 reserved TCP 4500, but did not specify how
> > to actually use TCP at all. It seems 

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

[Tommy Pauly]

> On Apr 26, 2017, at 1:08 PM, Ben Campbell  wrote:
> 
>> 
>> On Apr 26, 2017, at 2:58 PM, Spencer Dawkins at IETF 
>>  wrote:
>> 
>> Hi, Ben and Tommy,
>> 
>> On Wed, Apr 26, 2017 at 1:36 PM, Ben Campbell  wrote:
>> 
>>> On Apr 26, 2017, at 12:50 PM, Tommy Pauly  wrote:
>>> 
>>> Hi Ben,
>>> 
>>> Thanks for the comments! Your point about the line in Section 6 not making 
>>> sense is definitely a good point. How about this text (changes in bold):
>>> 
>>> If a TCP connection is being used to resume a previous IKE session,
>>>   the TCP Responder can recognize the session using either the IKE SPI
>>>   from an encapsulated IKE message or the ESP SPI from an encapsulated
>>>   ESP message.  If the session had been fully established previously,
>>>   it is suggested that the TCP Originator send an UPDATE_SA_ADDRESSES
>>>   message if MOBIKE is supported, or an INFORMATIONAL message (a
>>>   keepalive) otherwise.  [The TCP Responder MUST NOT accept any messages
>>>   for the existing IKE session on new an incoming connection unless that 
>>> connection
>>>   begins with the stream prefix. If either the TCP Originator or TCP 
>>> Responder
>>>   cannot parse valid IKE or ESP messages on a TCP encapsulation connection
>>>   that was started with a valid stream prefix, it MUST close the TCP 
>>> connection.]
>>>   If there is instead a syntax issue within an IKE
>>>   message, an implementation MUST send the INVALID_SYNTAX notify
>>>   payload and tear down the IKE SA as usual, rather than tearing down
>>>   the TCP connection directly.
>>> 
>>> Thanks,
>>> Tommy
>> 
>> That looks good to me. I will clear, with the assumption this or similar 
>> edits will make it into the draft.
>> 
>> Does 
>> 
>> The TCP Responder MUST NOT accept any messages
>>   for the existing IKE session on new an incoming connection unless that 
>> connection
>>   begins with the stream prefix. 
>> 
>> parse for you guys? I get stuck at "on new an incoming”.
> 
> 
> I’m guessing that’s an edit-o from. Maybe it should be “on a new incoming”?

Yes, I meant "on a new incoming connection". Sorry!

Thanks,
Tommy
> 
>> 
>> Spencer
>> 
>> 
>> Thanks!
>> 
>> Ben.
>> 
>> 
>>> 
 On Apr 26, 2017, at 8:35 AM, Ben Campbell  wrote:
 
 By the way, the DISCUSS vs COMMENT framing has gotten lost from the 
 thread. Only the first point was part of the DISCUSS, the rest are 
 non-binding comments. And I think the DISCUSS point is moving in the right 
 direction, pending a text proposal.
 
 Thanks!
 
 Ben.
 
> On Apr 26, 2017, at 8:57 AM, Kathleen Moriarty 
>  wrote:
> 
> On Tue, Apr 25, 2017 at 11:54 PM, Ben Campbell  wrote:
>> 
>>> On Apr 25, 2017, at 9:38 PM, Kathleen Moriarty 
>>>  wrote:
>>> 
>>> Thanks for the quick response Paul, a few questions...
>>> 
>>> On Tue, Apr 25, 2017 at 10:18 PM, Paul Wouters  wrote:
 On Tue, 25 Apr 2017, Kathleen Moriarty wrote:
 
>> IIUC, the entire point of having the stream prefix is to allow the 
>> TCP
>> responder to demux between this protocol, and some other protocol 
>> that
>> would normally run on that port. Saying it MUST close the TCP session
>> seems to completely remove that value. I assume people meant to 
>> allow the
>> respondent to delegate a stream out to some other protocol handler 
>> if the
>> prefix is not present?
>> 
> 
> I believe that this is because there is presumed to be no other
> service operating on the listening port (assuming a VPN concentrator),
> but that's not explicitly stated either.
 
 
 Vendors tend to run TLS on the IKE/IPsec machine, either to offer one 
 of
 the other kinds of SSL VPNs or as the administration interface or
 user interface.
>>> 
>>> OK, sounds like I didn't help here, so the editors should propose text
>>> to address this gap.
>> 
>> I think we are on the right track here, pending proposed text.
>> 
>>> 
 
>> -- 2nd to last paragraph: "This document leaves the selection of TCP
>> ports up to implementations."
>> I suspect "configurable local policy" would make more sense. Leaving 
>> it
>> up to "implementations" leaves open the chance of different
>> implementations making non-intersecting port choices, which doesn't 
>> help
>> interoperability.
> 
> 
> This may go more into unexplained assumptions... the clients
> authorized to connect to the server would need to know the correct
> port to establish a session and would be given that information

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

[Ben Campbell]

> On Apr 26, 2017, at 2:58 PM, Spencer Dawkins at IETF 
>  wrote:
> 
> Hi, Ben and Tommy,
> 
> On Wed, Apr 26, 2017 at 1:36 PM, Ben Campbell  wrote:
> 
> > On Apr 26, 2017, at 12:50 PM, Tommy Pauly  wrote:
> >
> > Hi Ben,
> >
> > Thanks for the comments! Your point about the line in Section 6 not making 
> > sense is definitely a good point. How about this text (changes in bold):
> >
> > If a TCP connection is being used to resume a previous IKE session,
> >the TCP Responder can recognize the session using either the IKE SPI
> >from an encapsulated IKE message or the ESP SPI from an encapsulated
> >ESP message.  If the session had been fully established previously,
> >it is suggested that the TCP Originator send an UPDATE_SA_ADDRESSES
> >message if MOBIKE is supported, or an INFORMATIONAL message (a
> >keepalive) otherwise.  [The TCP Responder MUST NOT accept any messages
> >for the existing IKE session on new an incoming connection unless that 
> > connection
> >begins with the stream prefix. If either the TCP Originator or TCP 
> > Responder
> >cannot parse valid IKE or ESP messages on a TCP encapsulation connection
> >that was started with a valid stream prefix, it MUST close the TCP 
> > connection.]
> >If there is instead a syntax issue within an IKE
> >message, an implementation MUST send the INVALID_SYNTAX notify
> >payload and tear down the IKE SA as usual, rather than tearing down
> >the TCP connection directly.
> >
> > Thanks,
> > Tommy
> 
> That looks good to me. I will clear, with the assumption this or similar 
> edits will make it into the draft.
> 
> Does 
> 
> The TCP Responder MUST NOT accept any messages
>for the existing IKE session on new an incoming connection unless that 
> connection
>begins with the stream prefix. 
> 
> parse for you guys? I get stuck at "on new an incoming”.


I’m guessing that’s an edit-o from. Maybe it should be “on a new incoming”?

> 
> Spencer
>  
> 
> Thanks!
> 
> Ben.
> 
> 
> >
> >> On Apr 26, 2017, at 8:35 AM, Ben Campbell  wrote:
> >>
> >> By the way, the DISCUSS vs COMMENT framing has gotten lost from the 
> >> thread. Only the first point was part of the DISCUSS, the rest are 
> >> non-binding comments. And I think the DISCUSS point is moving in the right 
> >> direction, pending a text proposal.
> >>
> >> Thanks!
> >>
> >> Ben.
> >>
> >>> On Apr 26, 2017, at 8:57 AM, Kathleen Moriarty 
> >>>  wrote:
> >>>
> >>> On Tue, Apr 25, 2017 at 11:54 PM, Ben Campbell  wrote:
> 
> > On Apr 25, 2017, at 9:38 PM, Kathleen Moriarty 
> >  wrote:
> >
> > Thanks for the quick response Paul, a few questions...
> >
> > On Tue, Apr 25, 2017 at 10:18 PM, Paul Wouters  wrote:
> >> On Tue, 25 Apr 2017, Kathleen Moriarty wrote:
> >>
>  IIUC, the entire point of having the stream prefix is to allow the 
>  TCP
>  responder to demux between this protocol, and some other protocol 
>  that
>  would normally run on that port. Saying it MUST close the TCP session
>  seems to completely remove that value. I assume people meant to 
>  allow the
>  respondent to delegate a stream out to some other protocol handler 
>  if the
>  prefix is not present?
> 
> >>>
> >>> I believe that this is because there is presumed to be no other
> >>> service operating on the listening port (assuming a VPN concentrator),
> >>> but that's not explicitly stated either.
> >>
> >>
> >> Vendors tend to run TLS on the IKE/IPsec machine, either to offer one 
> >> of
> >> the other kinds of SSL VPNs or as the administration interface or
> >> user interface.
> >
> > OK, sounds like I didn't help here, so the editors should propose text
> > to address this gap.
> 
>  I think we are on the right track here, pending proposed text.
> 
> >
> >>
>  -- 2nd to last paragraph: "This document leaves the selection of TCP
>  ports up to implementations."
>  I suspect "configurable local policy" would make more sense. Leaving 
>  it
>  up to "implementations" leaves open the chance of different
>  implementations making non-intersecting port choices, which doesn't 
>  help
>  interoperability.
> >>>
> >>>
> >>> This may go more into unexplained assumptions... the clients
> >>> authorized to connect to the server would need to know the correct
> >>> port to establish a session and would be given that information
> >>> specific to the implementation.  With this assumption, the above
> >>> should be fine... but editors/AD/WG, please correct me if I am wrong.
> >>
> >>
> >> I am pretty 

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

[Spencer Dawkins at IETF]

Hi, Ben and Tommy,

On Wed, Apr 26, 2017 at 1:36 PM, Ben Campbell  wrote:

>
> > On Apr 26, 2017, at 12:50 PM, Tommy Pauly  wrote:
> >
> > Hi Ben,
> >
> > Thanks for the comments! Your point about the line in Section 6 not
> making sense is definitely a good point. How about this text (changes in
> bold):
> >
> > If a TCP connection is being used to resume a previous IKE session,
> >the TCP Responder can recognize the session using either the IKE SPI
> >from an encapsulated IKE message or the ESP SPI from an encapsulated
> >ESP message.  If the session had been fully established previously,
> >it is suggested that the TCP Originator send an UPDATE_SA_ADDRESSES
> >message if MOBIKE is supported, or an INFORMATIONAL message (a
> >keepalive) otherwise.  [The TCP Responder MUST NOT accept any messages
> >for the existing IKE session on new an incoming connection unless
> that connection
> >begins with the stream prefix. If either the TCP Originator or TCP
> Responder
> >cannot parse valid IKE or ESP messages on a TCP encapsulation
> connection
> >that was started with a valid stream prefix, it MUST close the TCP
> connection.]
> >If there is instead a syntax issue within an IKE
> >message, an implementation MUST send the INVALID_SYNTAX notify
> >payload and tear down the IKE SA as usual, rather than tearing down
> >the TCP connection directly.
> >
> > Thanks,
> > Tommy
>
> That looks good to me. I will clear, with the assumption this or similar
> edits will make it into the draft.
>

Does

*The TCP Responder MUST NOT accept any messages*
*   for the existing IKE session on new an incoming connection unless that
connection*
*   begins with the stream prefix. *

parse for you guys? I get stuck at "on new an incoming".

Spencer


>
> Thanks!
>
> Ben.
>
>
> >
> >> On Apr 26, 2017, at 8:35 AM, Ben Campbell  wrote:
> >>
> >> By the way, the DISCUSS vs COMMENT framing has gotten lost from the
> thread. Only the first point was part of the DISCUSS, the rest are
> non-binding comments. And I think the DISCUSS point is moving in the right
> direction, pending a text proposal.
> >>
> >> Thanks!
> >>
> >> Ben.
> >>
> >>> On Apr 26, 2017, at 8:57 AM, Kathleen Moriarty <
> kathleen.moriarty.i...@gmail.com> wrote:
> >>>
> >>> On Tue, Apr 25, 2017 at 11:54 PM, Ben Campbell 
> wrote:
> 
> > On Apr 25, 2017, at 9:38 PM, Kathleen Moriarty <
> kathleen.moriarty.i...@gmail.com> wrote:
> >
> > Thanks for the quick response Paul, a few questions...
> >
> > On Tue, Apr 25, 2017 at 10:18 PM, Paul Wouters 
> wrote:
> >> On Tue, 25 Apr 2017, Kathleen Moriarty wrote:
> >>
>  IIUC, the entire point of having the stream prefix is to allow
> the TCP
>  responder to demux between this protocol, and some other protocol
> that
>  would normally run on that port. Saying it MUST close the TCP
> session
>  seems to completely remove that value. I assume people meant to
> allow the
>  respondent to delegate a stream out to some other protocol
> handler if the
>  prefix is not present?
> 
> >>>
> >>> I believe that this is because there is presumed to be no other
> >>> service operating on the listening port (assuming a VPN
> concentrator),
> >>> but that's not explicitly stated either.
> >>
> >>
> >> Vendors tend to run TLS on the IKE/IPsec machine, either to offer
> one of
> >> the other kinds of SSL VPNs or as the administration interface or
> >> user interface.
> >
> > OK, sounds like I didn't help here, so the editors should propose
> text
> > to address this gap.
> 
>  I think we are on the right track here, pending proposed text.
> 
> >
> >>
>  -- 2nd to last paragraph: "This document leaves the selection of
> TCP
>  ports up to implementations."
>  I suspect "configurable local policy" would make more sense.
> Leaving it
>  up to "implementations" leaves open the chance of different
>  implementations making non-intersecting port choices, which
> doesn't help
>  interoperability.
> >>>
> >>>
> >>> This may go more into unexplained assumptions... the clients
> >>> authorized to connect to the server would need to know the correct
> >>> port to establish a session and would be given that information
> >>> specific to the implementation.  With this assumption, the above
> >>> should be fine... but editors/AD/WG, please correct me if I am
> wrong.
> >>
> >>
> >> I am pretty sure what is meant is "configuration" and not
> "implementation".
> >
> > Is that in response to me being wrong in my assumption or the draft
> > should say configuration (I think it's the latter, but important to
> > check)?
> 
>  We are probably splitting hairs on the 

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

[Eric Rescorla]

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?

Tommy, Tero, the stream prefix doesn't seem totally ideal. Would there be
wiggle room
to specify ALPN here? Or maybe a longer prefix?

-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
> obsoleted protocol defined in the RFC3947. It does define way to
> extend things in IKE in similar way than RFC3948 (UDPENCAPS) does. On
> the other hand RFC3947 should have been obsoleted when we obsoleted
> IKEv1, as that document only defines how to do IKEv1 NAT traversal
> negotiation, and the IKEv2 NAT traversal negotation is described in
> main IKEv2 RFC (RFC7296).
>
> > It's a little weird. 3947 reserved TCP 4500, but did not specify how
> > to actually use TCP at all. It seems it was mostly preventatively
> > reserved.
>
> The reason RFC3947 reserved TCP/4500 was that it updated both TCP/4500
> and UDP/4500 references from individual user to the RFC3947, so that
> IETF will have change control over the ports. I.e., those ports were
> allocated before RFC3947 came out, and they were used for several
> different non-interoperable versions of the NAT traversals, which then
> evolved to the standard version we define in RFC3947. We decided to
> reassign both TCP and UDP port 4500 to RFC3947 so it would be clear
> for what use they will be used. Also we commonly reserve both TCP and
> UDP ports for same number just in case someone defines a way to run
> the protocol over other transport protocol in the future...
>
> RFC3947 does not define anything over TCP/4500. Actually RFC3947 does
> not define anything over the UDP/4500 either, it is the RFC3948 that
> does that. The RFC3947 just says, we use the format defined in the
> RFC3948 over the UDP/4500, but is silent about the TCP/4500.
>
> RFC3947 is efficiently obsoleted, as it only defines the way to do NAT
> traversal on IKEv1, and IKEv1 

[IPsec] Spencer Dawkins' No Objection on draft-ietf-ipsecme-tcp-encaps-09: (with COMMENT)

[Spencer Dawkins]

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

I support Mirja's Discuss, and am happy with the direction that
discussing is headed.


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

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

[Ben Campbell]

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

Update: Thanks for proposing text to address my DISCUSS point. I've
cleared the discuss, with the assumption the proposed edit (or similar)
will make it into the draft.

Substantive Comments:

-2:
-- 2nd bullet (and elsewhere)
I think this needs a discussion about how those configured ports are
likely to be in the assigned range, and the likely impact. (I recognize
that tunneling over a port assigned to something else is a primary reason
for doing this. I'm not arguing against it; I just think the implications
warrant discussion.)

-- 2nd to last paragraph: "This document leaves the selection of TCP
ports up to implementations."
I suspect "configurable local policy" would make more sense. Leaving it
up to "implementations" leaves open the chance of different
implementations making non-intersecting port choices, which doesn't help
interoperability.

-3, first paragraph:
Are people confident there will never, ever be a need to demux protocols
other than IKE and ESP? If not, this approach may paint people in a
corner in the future. I ask because we made similar choices with
DTLS-SRTP [RFC5764] in demuxing DTLS and STUN, and it became an issue.
See RFC7983 for a discussion. (Note that this would have been a DISCUSS
point, but I think it's reasonably likely that there really won't be
other protocols here. But I want to make sure people have thought about
it.)

-4, first paragraph: What is the expected behavior from a peers that do
not support this spec when they receive a TCP stream with the magic
number on a port for some other protocol?

-6: First paragraph: It would be helpful to mention behavior on receipt
of a stream without the magic number here. But see the DISCUSS point.

-8: "... MUST support dynamically enabling and disabling TCP
encapsulation..." seems unreasonably strong, especially since the
requirement to try UDP before TCP is only a SHOULD. Does this contemplate
situations where it might be impossible to use TCP on the after a network
change?

- Appendix A: Doesn't the use of the NULL cipher invalidate one of the
primary reasons to use TLS? (Namely to obscure the fact that this is not
HTTP, or whatever other protocol is assigned to the port?)

Editorial Comments:

- Please expand IKE and ESP on first mention in both the abstract and
body.

-3, 2nd paragraph: s/"may be able"/"is able".

-3.2, " The SPI field in the ESP header MUST NOT be a zero value."
Is this a new requirement for this draft? That is, does ESP otherwise
allow zero value SPIs? If not, please consider dropping the MUST NOT.  

-5.1: "...SHOULD always attempt negotiate IKE over UDP first"
This is stated several times in the draft, more than once with the
SHOULD. It's better to avoid redundant 2119 keywords.

-6: "... IKE Figure 1 and ESP Figure 2... ": Broken section
cross-references.

-10, title: Please expand DPD.

-12: Several previous sections pointed to section 12 for more information
about why one needed to try direct connections or UDP before TCP. But I
don't find any specifics on that in this section.

- Appendix A: Why is this an appendix? It contains normative text that
seems central to certain use cases. I was surprised to see no discussion
about using TLS in section 11, where it seemed quite relevant.


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

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

[Joe Touch]

On 4/25/2017 8:46 PM, Yoav Nir wrote:
> ...
>>> While it is the default port for HTTPS, that protocol can run on any
>>> port depending on the value in origin (RFC 6454).
>>
>> Yes, any protocol can run on any port number (as per above), as long
>> as the endpoints agree. But that's not what you're talking about here
>> - you're saying that if you get "IKETCP" on a port, then you can
>> trust that it is your service.
>>
>> That's incorrect. You don't get to define the string "IKETCP" for
>> other services.
>
> That I totally agree with.  The purpose of the IKETCP magic string is
> to demultiplex between TCP connections implementing this draft and
> other TCP connections using the same port for other services,
> regardless of whether those other services are defined in IANA or
> other squatters.

Actually, this is the opposite of what is valid.

Let me be clear - you can define that string to mean whatever you want
WITHIN YOUR SERVICE.

You CANNOT define that string as having a meaning when a port is used
for other services. You cannot change other services without updating
their specs (and without their permission).

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

IMO, that section needs substantial revision and must not say - or imply
- what it currently says.

Joe

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

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

[Joe Touch]

Hi, Tommy,


On 4/25/2017 8:34 PM, Tommy Pauly wrote:
> I suggest that we can:
>
> - Clarify the text in section 2 (configuration) to say that the
> default port is TCP 4500, and that implementations may communicate
> other port options out of band as configuration. This is done for UDP
> as well. This is the "explicit" indication of the ports you mention above.
> - Port 443 is only mentioned in the figures for the appendix. We can
> remove the mention of the port there.
That will work.

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

That is your decision, but IMO it is important that this ONLY helps
check that you connect to a port running your service based on other
information (e.g., port 4500 or port as indicated out of band). The key
issue is that this doc should never claim that this text is intended to
help you run this service *concurrently* with any other service on the
same port. That's hijacking - because any existing service can define
that string to mean whatever it wants (regardless of whether they do
that now or not).

> TCP port 4500 has been technically allocated to IPsec NAT Traversal
> (which TCP encapsulation is) for a long while without a specific
> protocol being defined. The concern that brought about the stream
> prefix was to let VPN endpoints that may be running older non-standard
> protocols to recognize TCP encapsulation in case they were already
> squatting on the port (4500), or have configured TCP encapsulation to
> run on a port they are using for their own custom VPN protocol.
>
> How does that sound?

As a confirmation check, yes. Again, NOT to demux with legacy services.

Joe



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

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

[Tommy Pauly]

Hi Ben,

Thanks for the comments! Your point about the line in Section 6 not making 
sense is definitely a good point. How about this text (changes in bold):

If a TCP connection is being used to resume a previous IKE session,
   the TCP Responder can recognize the session using either the IKE SPI
   from an encapsulated IKE message or the ESP SPI from an encapsulated
   ESP message.  If the session had been fully established previously,
   it is suggested that the TCP Originator send an UPDATE_SA_ADDRESSES
   message if MOBIKE is supported, or an INFORMATIONAL message (a
   keepalive) otherwise.  [The TCP Responder MUST NOT accept any messages
   for the existing IKE session on new an incoming connection unless that 
connection
   begins with the stream prefix. If either the TCP Originator or TCP Responder
   cannot parse valid IKE or ESP messages on a TCP encapsulation connection
   that was started with a valid stream prefix, it MUST close the TCP 
connection.]  
   If there is instead a syntax issue within an IKE
   message, an implementation MUST send the INVALID_SYNTAX notify
   payload and tear down the IKE SA as usual, rather than tearing down
   the TCP connection directly.

Thanks,
Tommy

> On Apr 26, 2017, at 8:35 AM, Ben Campbell  wrote:
> 
> By the way, the DISCUSS vs COMMENT framing has gotten lost from the thread. 
> Only the first point was part of the DISCUSS, the rest are non-binding 
> comments. And I think the DISCUSS point is moving in the right direction, 
> pending a text proposal.
> 
> Thanks!
> 
> Ben.
> 
>> On Apr 26, 2017, at 8:57 AM, Kathleen Moriarty 
>>  wrote:
>> 
>> On Tue, Apr 25, 2017 at 11:54 PM, Ben Campbell  wrote:
>>> 
 On Apr 25, 2017, at 9:38 PM, Kathleen Moriarty 
  wrote:
 
 Thanks for the quick response Paul, a few questions...
 
 On Tue, Apr 25, 2017 at 10:18 PM, Paul Wouters  wrote:
> On Tue, 25 Apr 2017, Kathleen Moriarty wrote:
> 
>>> IIUC, the entire point of having the stream prefix is to allow the TCP
>>> responder to demux between this protocol, and some other protocol that
>>> would normally run on that port. Saying it MUST close the TCP session
>>> seems to completely remove that value. I assume people meant to allow 
>>> the
>>> respondent to delegate a stream out to some other protocol handler if 
>>> the
>>> prefix is not present?
>>> 
>> 
>> I believe that this is because there is presumed to be no other
>> service operating on the listening port (assuming a VPN concentrator),
>> but that's not explicitly stated either.
> 
> 
> Vendors tend to run TLS on the IKE/IPsec machine, either to offer one of
> the other kinds of SSL VPNs or as the administration interface or
> user interface.
 
 OK, sounds like I didn't help here, so the editors should propose text
 to address this gap.
>>> 
>>> I think we are on the right track here, pending proposed text.
>>> 
 
> 
>>> -- 2nd to last paragraph: "This document leaves the selection of TCP
>>> ports up to implementations."
>>> I suspect "configurable local policy" would make more sense. Leaving it
>>> up to "implementations" leaves open the chance of different
>>> implementations making non-intersecting port choices, which doesn't help
>>> interoperability.
>> 
>> 
>> This may go more into unexplained assumptions... the clients
>> authorized to connect to the server would need to know the correct
>> port to establish a session and would be given that information
>> specific to the implementation.  With this assumption, the above
>> should be fine... but editors/AD/WG, please correct me if I am wrong.
> 
> 
> I am pretty sure what is meant is "configuration" and not 
> "implementation".
 
 Is that in response to me being wrong in my assumption or the draft
 should say configuration (I think it's the latter, but important to
 check)?
>>> 
>>> We are probably splitting hairs on the meaning of “implementation” vs 
>>> “configuration”. (and maybe “deployment”). I was thinking of 
>>> “implementation” as being what developers do, and “configuring/deploying” 
>>> as what operators do. But I am aware that operators sometimes talk about 
>>> “implementing” a system.
>>> 
>>> So my point was that I assume for purposes of interoperability that a 
>>> general purpose client or server would allow the port to be changed in the 
>>> field.
>>> 
 
> 
>>> -4, first paragraph: What is the expected behavior from a peers that do
>>> not support this spec when they receive a TCP stream with the magic
>>> number on a port for some other protocol?
>> 
>> 
>> Maybe listing assumptions up front in the draft would help _IF_ the
>> assumption is that the listening server is a 

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

[Michael Richardson]

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

+1.  Paul speaks sense here.

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

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

--
Michael Richardson , Sandelman Software Works
 -= IPv6 IoT consulting =-





signature.asc
Description: PGP signature
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Ben Campbell]

By the way, the DISCUSS vs COMMENT framing has gotten lost from the thread. 
Only the first point was part of the DISCUSS, the rest are non-binding 
comments. And I think the DISCUSS point is moving in the right direction, 
pending a text proposal.

Thanks!

Ben.

> On Apr 26, 2017, at 8:57 AM, Kathleen Moriarty 
>  wrote:
> 
> On Tue, Apr 25, 2017 at 11:54 PM, Ben Campbell  wrote:
>> 
>>> On Apr 25, 2017, at 9:38 PM, Kathleen Moriarty 
>>>  wrote:
>>> 
>>> Thanks for the quick response Paul, a few questions...
>>> 
>>> On Tue, Apr 25, 2017 at 10:18 PM, Paul Wouters  wrote:
 On Tue, 25 Apr 2017, Kathleen Moriarty wrote:
 
>> IIUC, the entire point of having the stream prefix is to allow the TCP
>> responder to demux between this protocol, and some other protocol that
>> would normally run on that port. Saying it MUST close the TCP session
>> seems to completely remove that value. I assume people meant to allow the
>> respondent to delegate a stream out to some other protocol handler if the
>> prefix is not present?
>> 
> 
> I believe that this is because there is presumed to be no other
> service operating on the listening port (assuming a VPN concentrator),
> but that's not explicitly stated either.
 
 
 Vendors tend to run TLS on the IKE/IPsec machine, either to offer one of
 the other kinds of SSL VPNs or as the administration interface or
 user interface.
>>> 
>>> OK, sounds like I didn't help here, so the editors should propose text
>>> to address this gap.
>> 
>> I think we are on the right track here, pending proposed text.
>> 
>>> 
 
>> -- 2nd to last paragraph: "This document leaves the selection of TCP
>> ports up to implementations."
>> I suspect "configurable local policy" would make more sense. Leaving it
>> up to "implementations" leaves open the chance of different
>> implementations making non-intersecting port choices, which doesn't help
>> interoperability.
> 
> 
> This may go more into unexplained assumptions... the clients
> authorized to connect to the server would need to know the correct
> port to establish a session and would be given that information
> specific to the implementation.  With this assumption, the above
> should be fine... but editors/AD/WG, please correct me if I am wrong.
 
 
 I am pretty sure what is meant is "configuration" and not "implementation".
>>> 
>>> Is that in response to me being wrong in my assumption or the draft
>>> should say configuration (I think it's the latter, but important to
>>> check)?
>> 
>> We are probably splitting hairs on the meaning of “implementation” vs 
>> “configuration”. (and maybe “deployment”). I was thinking of 
>> “implementation” as being what developers do, and “configuring/deploying” as 
>> what operators do. But I am aware that operators sometimes talk about 
>> “implementing” a system.
>> 
>> So my point was that I assume for purposes of interoperability that a 
>> general purpose client or server would allow the port to be changed in the 
>> field.
>> 
>>> 
 
>> -4, first paragraph: What is the expected behavior from a peers that do
>> not support this spec when they receive a TCP stream with the magic
>> number on a port for some other protocol?
> 
> 
> Maybe listing assumptions up front in the draft would help _IF_ the
> assumption is that the listening server is a VPN concentrator that
> wouldn't be listening for other services.
 
 
 Support for TCP would be based on preconfiguration, so the client knows
 this out-of-band. It cannot be discovered during negotiation, because
 it is assumed the regular UDP ports are blocked, which is the only
 reason to attempt TCP to begin with.
>>> 
>>> I read the draft with this assumption in mind (see above), but this
>>> should be clarified in the document to address this question from Ben.
>> 
>> Imagine a misconfigured client opening a connection to an web server on port 
>> 80, expecting to find a VPN service. What happens? I think that a 
>> consequence of the design approach to allow this to run over ports assigned 
>> to other protocols is that you need to consider that sort of thing.
>> 
 
>> - Appendix A: Doesn't the use of the NULL cipher invalidate one of the
>> primary reasons to use TLS? (Namely to obscure the fact that this is not
>> HTTP, or whatever other protocol is assigned to the port?)
> 
> 
> Editors/AD correct me if I am wrong, but...
> No, if TLS is used with a NULL cipher, it'll pass inspection of a
> middle box validating the protocol.  This doesn't need to use the
> cipher as it's negotiating the IPsec connection.
 
 
 right, TLS happens to use encryption to get out, but it is not the
 encryption of the 

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

[Eric Rescorla]

On Wed, Apr 26, 2017 at 8:13 AM, Kathleen Moriarty <
kathleen.moriarty.i...@gmail.com> wrote:

> On Wed, Apr 26, 2017 at 11:05 AM, Eric Rescorla  wrote:
> >
> >
> > On Wed, Apr 26, 2017 at 6:57 AM, Kathleen Moriarty
> >  wrote:
> >>
> >> On Tue, Apr 25, 2017 at 11:54 PM, Ben Campbell  wrote:
> >> >
> >> >> On Apr 25, 2017, at 9:38 PM, Kathleen Moriarty
> >> >>  wrote:
> >> >>
> >> >> Thanks for the quick response Paul, a few questions...
> >> >>
> >> >> On Tue, Apr 25, 2017 at 10:18 PM, Paul Wouters 
> wrote:
> >> >>> On Tue, 25 Apr 2017, Kathleen Moriarty wrote:
> >> >>>
> >> > IIUC, the entire point of having the stream prefix is to allow the
> >> > TCP
> >> > responder to demux between this protocol, and some other protocol
> >> > that
> >> > would normally run on that port. Saying it MUST close the TCP
> >> > session
> >> > seems to completely remove that value. I assume people meant to
> >> > allow the
> >> > respondent to delegate a stream out to some other protocol handler
> >> > if the
> >> > prefix is not present?
> >> >
> >> 
> >>  I believe that this is because there is presumed to be no other
> >>  service operating on the listening port (assuming a VPN
> >>  concentrator),
> >>  but that's not explicitly stated either.
> >> >>>
> >> >>>
> >> >>> Vendors tend to run TLS on the IKE/IPsec machine, either to offer
> one
> >> >>> of
> >> >>> the other kinds of SSL VPNs or as the administration interface or
> >> >>> user interface.
> >> >>
> >> >> OK, sounds like I didn't help here, so the editors should propose
> text
> >> >> to address this gap.
> >> >
> >> > I think we are on the right track here, pending proposed text.
> >> >
> >> >>
> >> >>>
> >> > -- 2nd to last paragraph: "This document leaves the selection of
> TCP
> >> > ports up to implementations."
> >> > I suspect "configurable local policy" would make more sense.
> Leaving
> >> > it
> >> > up to "implementations" leaves open the chance of different
> >> > implementations making non-intersecting port choices, which
> doesn't
> >> > help
> >> > interoperability.
> >> 
> >> 
> >>  This may go more into unexplained assumptions... the clients
> >>  authorized to connect to the server would need to know the correct
> >>  port to establish a session and would be given that information
> >>  specific to the implementation.  With this assumption, the above
> >>  should be fine... but editors/AD/WG, please correct me if I am
> wrong.
> >> >>>
> >> >>>
> >> >>> I am pretty sure what is meant is "configuration" and not
> >> >>> "implementation".
> >> >>
> >> >> Is that in response to me being wrong in my assumption or the draft
> >> >> should say configuration (I think it's the latter, but important to
> >> >> check)?
> >> >
> >> > We are probably splitting hairs on the meaning of “implementation” vs
> >> > “configuration”. (and maybe “deployment”). I was thinking of
> >> > “implementation” as being what developers do, and
> “configuring/deploying” as
> >> > what operators do. But I am aware that operators sometimes talk about
> >> > “implementing” a system.
> >> >
> >> > So my point was that I assume for purposes of interoperability that a
> >> > general purpose client or server would allow the port to be changed
> in the
> >> > field.
> >> >
> >> >>
> >> >>>
> >> > -4, first paragraph: What is the expected behavior from a peers
> that
> >> > do
> >> > not support this spec when they receive a TCP stream with the
> magic
> >> > number on a port for some other protocol?
> >> 
> >> 
> >>  Maybe listing assumptions up front in the draft would help _IF_ the
> >>  assumption is that the listening server is a VPN concentrator that
> >>  wouldn't be listening for other services.
> >> >>>
> >> >>>
> >> >>> Support for TCP would be based on preconfiguration, so the client
> >> >>> knows
> >> >>> this out-of-band. It cannot be discovered during negotiation,
> because
> >> >>> it is assumed the regular UDP ports are blocked, which is the only
> >> >>> reason to attempt TCP to begin with.
> >> >>
> >> >> I read the draft with this assumption in mind (see above), but this
> >> >> should be clarified in the document to address this question from
> Ben.
> >> >
> >> > Imagine a misconfigured client opening a connection to an web server
> on
> >> > port 80, expecting to find a VPN service. What happens? I think that a
> >> > consequence of the design approach to allow this to run over ports
> assigned
> >> > to other protocols is that you need to consider that sort of thing.
> >> >
> >> >>>
> >> > - Appendix A: Doesn't the use of the NULL cipher invalidate one of
> >> > the
> >> > primary reasons to use TLS? (Namely to obscure the fact that this
> is
> >> > not
> >> > 

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

[Alexey Melnikov]

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

2.  Configuration

   o  Optionally, an extra framing protocol to use on top of TCP to
  further encapsulate the stream of IKE and IPsec packets.  See
  Appendix A for a detailed discussion.

As Appendix A just talks about TLS, why not say this here explicitly? The
sentence above make it sound like this
is something outside of scope for the document and Appendix A talks about
generic way to encapsulate.


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

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

[Kathleen Moriarty]

On Wed, Apr 26, 2017 at 11:05 AM, Eric Rescorla  wrote:
>
>
> On Wed, Apr 26, 2017 at 6:57 AM, Kathleen Moriarty
>  wrote:
>>
>> On Tue, Apr 25, 2017 at 11:54 PM, Ben Campbell  wrote:
>> >
>> >> On Apr 25, 2017, at 9:38 PM, Kathleen Moriarty
>> >>  wrote:
>> >>
>> >> Thanks for the quick response Paul, a few questions...
>> >>
>> >> On Tue, Apr 25, 2017 at 10:18 PM, Paul Wouters  wrote:
>> >>> On Tue, 25 Apr 2017, Kathleen Moriarty wrote:
>> >>>
>> > IIUC, the entire point of having the stream prefix is to allow the
>> > TCP
>> > responder to demux between this protocol, and some other protocol
>> > that
>> > would normally run on that port. Saying it MUST close the TCP
>> > session
>> > seems to completely remove that value. I assume people meant to
>> > allow the
>> > respondent to delegate a stream out to some other protocol handler
>> > if the
>> > prefix is not present?
>> >
>> 
>>  I believe that this is because there is presumed to be no other
>>  service operating on the listening port (assuming a VPN
>>  concentrator),
>>  but that's not explicitly stated either.
>> >>>
>> >>>
>> >>> Vendors tend to run TLS on the IKE/IPsec machine, either to offer one
>> >>> of
>> >>> the other kinds of SSL VPNs or as the administration interface or
>> >>> user interface.
>> >>
>> >> OK, sounds like I didn't help here, so the editors should propose text
>> >> to address this gap.
>> >
>> > I think we are on the right track here, pending proposed text.
>> >
>> >>
>> >>>
>> > -- 2nd to last paragraph: "This document leaves the selection of TCP
>> > ports up to implementations."
>> > I suspect "configurable local policy" would make more sense. Leaving
>> > it
>> > up to "implementations" leaves open the chance of different
>> > implementations making non-intersecting port choices, which doesn't
>> > help
>> > interoperability.
>> 
>> 
>>  This may go more into unexplained assumptions... the clients
>>  authorized to connect to the server would need to know the correct
>>  port to establish a session and would be given that information
>>  specific to the implementation.  With this assumption, the above
>>  should be fine... but editors/AD/WG, please correct me if I am wrong.
>> >>>
>> >>>
>> >>> I am pretty sure what is meant is "configuration" and not
>> >>> "implementation".
>> >>
>> >> Is that in response to me being wrong in my assumption or the draft
>> >> should say configuration (I think it's the latter, but important to
>> >> check)?
>> >
>> > We are probably splitting hairs on the meaning of “implementation” vs
>> > “configuration”. (and maybe “deployment”). I was thinking of
>> > “implementation” as being what developers do, and “configuring/deploying” 
>> > as
>> > what operators do. But I am aware that operators sometimes talk about
>> > “implementing” a system.
>> >
>> > So my point was that I assume for purposes of interoperability that a
>> > general purpose client or server would allow the port to be changed in the
>> > field.
>> >
>> >>
>> >>>
>> > -4, first paragraph: What is the expected behavior from a peers that
>> > do
>> > not support this spec when they receive a TCP stream with the magic
>> > number on a port for some other protocol?
>> 
>> 
>>  Maybe listing assumptions up front in the draft would help _IF_ the
>>  assumption is that the listening server is a VPN concentrator that
>>  wouldn't be listening for other services.
>> >>>
>> >>>
>> >>> Support for TCP would be based on preconfiguration, so the client
>> >>> knows
>> >>> this out-of-band. It cannot be discovered during negotiation, because
>> >>> it is assumed the regular UDP ports are blocked, which is the only
>> >>> reason to attempt TCP to begin with.
>> >>
>> >> I read the draft with this assumption in mind (see above), but this
>> >> should be clarified in the document to address this question from Ben.
>> >
>> > Imagine a misconfigured client opening a connection to an web server on
>> > port 80, expecting to find a VPN service. What happens? I think that a
>> > consequence of the design approach to allow this to run over ports assigned
>> > to other protocols is that you need to consider that sort of thing.
>> >
>> >>>
>> > - Appendix A: Doesn't the use of the NULL cipher invalidate one of
>> > the
>> > primary reasons to use TLS? (Namely to obscure the fact that this is
>> > not
>> > HTTP, or whatever other protocol is assigned to the port?)
>> 
>> 
>>  Editors/AD correct me if I am wrong, but...
>>  No, if TLS is used with a NULL cipher, it'll pass inspection of a
>>  middle box validating the protocol.  This doesn't need to use the
>>  cipher as it's negotiating the IPsec connection.
>> >>>
>> >>>
>> 

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

[Eric Rescorla]

On Wed, Apr 26, 2017 at 6:57 AM, Kathleen Moriarty <
kathleen.moriarty.i...@gmail.com> wrote:

> On Tue, Apr 25, 2017 at 11:54 PM, Ben Campbell  wrote:
> >
> >> On Apr 25, 2017, at 9:38 PM, Kathleen Moriarty <
> kathleen.moriarty.i...@gmail.com> wrote:
> >>
> >> Thanks for the quick response Paul, a few questions...
> >>
> >> On Tue, Apr 25, 2017 at 10:18 PM, Paul Wouters  wrote:
> >>> On Tue, 25 Apr 2017, Kathleen Moriarty wrote:
> >>>
> > IIUC, the entire point of having the stream prefix is to allow the
> TCP
> > responder to demux between this protocol, and some other protocol
> that
> > would normally run on that port. Saying it MUST close the TCP session
> > seems to completely remove that value. I assume people meant to
> allow the
> > respondent to delegate a stream out to some other protocol handler
> if the
> > prefix is not present?
> >
> 
>  I believe that this is because there is presumed to be no other
>  service operating on the listening port (assuming a VPN concentrator),
>  but that's not explicitly stated either.
> >>>
> >>>
> >>> Vendors tend to run TLS on the IKE/IPsec machine, either to offer one
> of
> >>> the other kinds of SSL VPNs or as the administration interface or
> >>> user interface.
> >>
> >> OK, sounds like I didn't help here, so the editors should propose text
> >> to address this gap.
> >
> > I think we are on the right track here, pending proposed text.
> >
> >>
> >>>
> > -- 2nd to last paragraph: "This document leaves the selection of TCP
> > ports up to implementations."
> > I suspect "configurable local policy" would make more sense. Leaving
> it
> > up to "implementations" leaves open the chance of different
> > implementations making non-intersecting port choices, which doesn't
> help
> > interoperability.
> 
> 
>  This may go more into unexplained assumptions... the clients
>  authorized to connect to the server would need to know the correct
>  port to establish a session and would be given that information
>  specific to the implementation.  With this assumption, the above
>  should be fine... but editors/AD/WG, please correct me if I am wrong.
> >>>
> >>>
> >>> I am pretty sure what is meant is "configuration" and not
> "implementation".
> >>
> >> Is that in response to me being wrong in my assumption or the draft
> >> should say configuration (I think it's the latter, but important to
> >> check)?
> >
> > We are probably splitting hairs on the meaning of “implementation” vs
> “configuration”. (and maybe “deployment”). I was thinking of
> “implementation” as being what developers do, and “configuring/deploying”
> as what operators do. But I am aware that operators sometimes talk about
> “implementing” a system.
> >
> > So my point was that I assume for purposes of interoperability that a
> general purpose client or server would allow the port to be changed in the
> field.
> >
> >>
> >>>
> > -4, first paragraph: What is the expected behavior from a peers that
> do
> > not support this spec when they receive a TCP stream with the magic
> > number on a port for some other protocol?
> 
> 
>  Maybe listing assumptions up front in the draft would help _IF_ the
>  assumption is that the listening server is a VPN concentrator that
>  wouldn't be listening for other services.
> >>>
> >>>
> >>> Support for TCP would be based on preconfiguration, so the client knows
> >>> this out-of-band. It cannot be discovered during negotiation, because
> >>> it is assumed the regular UDP ports are blocked, which is the only
> >>> reason to attempt TCP to begin with.
> >>
> >> I read the draft with this assumption in mind (see above), but this
> >> should be clarified in the document to address this question from Ben.
> >
> > Imagine a misconfigured client opening a connection to an web server on
> port 80, expecting to find a VPN service. What happens? I think that a
> consequence of the design approach to allow this to run over ports assigned
> to other protocols is that you need to consider that sort of thing.
> >
> >>>
> > - Appendix A: Doesn't the use of the NULL cipher invalidate one of
> the
> > primary reasons to use TLS? (Namely to obscure the fact that this is
> not
> > HTTP, or whatever other protocol is assigned to the port?)
> 
> 
>  Editors/AD correct me if I am wrong, but...
>  No, if TLS is used with a NULL cipher, it'll pass inspection of a
>  middle box validating the protocol.  This doesn't need to use the
>  cipher as it's negotiating the IPsec connection.
> >>>
> >>>
> >>> right, TLS happens to use encryption to get out, but it is not the
> >>> encryption of the actual IKE/IPsec protocols, which keep using their
> >>> own channel negotiations.
> >>
> >> I think clarifying this further in the draft would be helpful.
> >
> > I agree, because I’m still confused :-)
> >
> 

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

[Kathleen Moriarty]

On Tue, Apr 25, 2017 at 11:54 PM, Ben Campbell  wrote:
>
>> On Apr 25, 2017, at 9:38 PM, Kathleen Moriarty 
>>  wrote:
>>
>> Thanks for the quick response Paul, a few questions...
>>
>> On Tue, Apr 25, 2017 at 10:18 PM, Paul Wouters  wrote:
>>> On Tue, 25 Apr 2017, Kathleen Moriarty wrote:
>>>
> IIUC, the entire point of having the stream prefix is to allow the TCP
> responder to demux between this protocol, and some other protocol that
> would normally run on that port. Saying it MUST close the TCP session
> seems to completely remove that value. I assume people meant to allow the
> respondent to delegate a stream out to some other protocol handler if the
> prefix is not present?
>

 I believe that this is because there is presumed to be no other
 service operating on the listening port (assuming a VPN concentrator),
 but that's not explicitly stated either.
>>>
>>>
>>> Vendors tend to run TLS on the IKE/IPsec machine, either to offer one of
>>> the other kinds of SSL VPNs or as the administration interface or
>>> user interface.
>>
>> OK, sounds like I didn't help here, so the editors should propose text
>> to address this gap.
>
> I think we are on the right track here, pending proposed text.
>
>>
>>>
> -- 2nd to last paragraph: "This document leaves the selection of TCP
> ports up to implementations."
> I suspect "configurable local policy" would make more sense. Leaving it
> up to "implementations" leaves open the chance of different
> implementations making non-intersecting port choices, which doesn't help
> interoperability.


 This may go more into unexplained assumptions... the clients
 authorized to connect to the server would need to know the correct
 port to establish a session and would be given that information
 specific to the implementation.  With this assumption, the above
 should be fine... but editors/AD/WG, please correct me if I am wrong.
>>>
>>>
>>> I am pretty sure what is meant is "configuration" and not "implementation".
>>
>> Is that in response to me being wrong in my assumption or the draft
>> should say configuration (I think it's the latter, but important to
>> check)?
>
> We are probably splitting hairs on the meaning of “implementation” vs 
> “configuration”. (and maybe “deployment”). I was thinking of “implementation” 
> as being what developers do, and “configuring/deploying” as what operators 
> do. But I am aware that operators sometimes talk about “implementing” a 
> system.
>
> So my point was that I assume for purposes of interoperability that a general 
> purpose client or server would allow the port to be changed in the field.
>
>>
>>>
> -4, first paragraph: What is the expected behavior from a peers that do
> not support this spec when they receive a TCP stream with the magic
> number on a port for some other protocol?


 Maybe listing assumptions up front in the draft would help _IF_ the
 assumption is that the listening server is a VPN concentrator that
 wouldn't be listening for other services.
>>>
>>>
>>> Support for TCP would be based on preconfiguration, so the client knows
>>> this out-of-band. It cannot be discovered during negotiation, because
>>> it is assumed the regular UDP ports are blocked, which is the only
>>> reason to attempt TCP to begin with.
>>
>> I read the draft with this assumption in mind (see above), but this
>> should be clarified in the document to address this question from Ben.
>
> Imagine a misconfigured client opening a connection to an web server on port 
> 80, expecting to find a VPN service. What happens? I think that a consequence 
> of the design approach to allow this to run over ports assigned to other 
> protocols is that you need to consider that sort of thing.
>
>>>
> - Appendix A: Doesn't the use of the NULL cipher invalidate one of the
> primary reasons to use TLS? (Namely to obscure the fact that this is not
> HTTP, or whatever other protocol is assigned to the port?)


 Editors/AD correct me if I am wrong, but...
 No, if TLS is used with a NULL cipher, it'll pass inspection of a
 middle box validating the protocol.  This doesn't need to use the
 cipher as it's negotiating the IPsec connection.
>>>
>>>
>>> right, TLS happens to use encryption to get out, but it is not the
>>> encryption of the actual IKE/IPsec protocols, which keep using their
>>> own channel negotiations.
>>
>> I think clarifying this further in the draft would be helpful.
>
> I agree, because I’m still confused :-)
>
> To clarify my question: Assuming the case of TLS encapsulation to the HTTPS 
> port across a DPI middle-box that hates that sort of thing. If TLS uses the 
> NULL cipher, can the middlebox not tell that the protocol over TLS is not 
> HTTP? (I will defer to the experts.)

IPsec WG participants should chime in 

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

[Tero Kivinen]

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. 

> -3.2, " The SPI field in the ESP header MUST NOT be a zero value."
> Is this a new requirement for this draft? That is, does ESP otherwise
> allow zero value SPIs? If not, please consider dropping the MUST NOT.  

RFC4303 reserves value zero for the "for local,
implementation-specific use and MUST NOT be sent on the wire.".

I.e., conforming ESP packet coming the to the UDP or TCP encapsulation
layer cannot have SPI of zero ever. And we are not using SPI zero, we
are using it as marker that this is not ESP packet, but this is IKE
packet.

The full text from the RFC4303 about the reserved SPI numbers is:
--
2.1.  Security Parameters Index (SPI)
...
   The set of SPI values in the range 1 through 255 are reserved by the
   Internet Assigned Numbers Authority (IANA) for future use; a reserved
   SPI value will not normally be assigned by IANA unless the use of the
   assigned SPI value is specified in an RFC.  The SPI value of zero (0)
   is reserved for local, implementation-specific use and MUST NOT be
   sent on the wire.  (For example, a key management implementation
   might use the zero SPI value to mean "No Security Association Exists"
   during the period when the IPsec implementation has requested that
   its key management entity establish a new SA, but the SA has not yet
   been established.)
-- 
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)

[Tero Kivinen]

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
obsoleted protocol defined in the RFC3947. It does define way to
extend things in IKE in similar way than RFC3948 (UDPENCAPS) does. On
the other hand RFC3947 should have been obsoleted when we obsoleted
IKEv1, as that document only defines how to do IKEv1 NAT traversal
negotiation, and the IKEv2 NAT traversal negotation is described in
main IKEv2 RFC (RFC7296).

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

The reason RFC3947 reserved TCP/4500 was that it updated both TCP/4500
and UDP/4500 references from individual user to the RFC3947, so that
IETF will have change control over the ports. I.e., those ports were
allocated before RFC3947 came out, and they were used for several
different non-interoperable versions of the NAT traversals, which then
evolved to the standard version we define in RFC3947. We decided to
reassign both TCP and UDP port 4500 to RFC3947 so it would be clear
for what use they will be used. Also we commonly reserve both TCP and
UDP ports for same number just in case someone defines a way to run
the protocol over other transport protocol in the future...

RFC3947 does not define anything over TCP/4500. Actually RFC3947 does
not define anything over the UDP/4500 either, it is the RFC3948 that
does that. The RFC3947 just says, we use the format defined in the
RFC3948 over the UDP/4500, but is silent about the TCP/4500.

RFC3947 is efficiently obsoleted, as it only defines the way to do NAT
traversal on IKEv1, and IKEv1 is obsoleted and replaced with IKEv2
(originally RFC4306, and now RFC7296). So the RFC3947 should have been
marked as obsoleted by RFC4306. I am not sure if we want to do that in
this late. 

So my proposal is update the IANA port registry for both UDP/4500 and
TCP/4500 as follows:

 Keyword   DecimalDescription  Reference
 ---   ------  -
 ipsec-nat-t   4500/tcp   IPsec NAT-Traversal  [RFC]
 ipsec-nat-t   4500/udp   IPsec NAT-Traversal  [RFC3948], [RFC7296]

(RFC being this RFC).

Note, that the RFC3947 on the 4500/UDP was changed to RFC3948 as the
RFC3948 actually defines the protocol used over the port. RFC3947
defines the IKEv1 negotiation over the UDP port 500 and 4500, but for
IKEv2 this is already defined in the RFC7296.

The RFC3947 could either be left as it is now, or marked as being
obsoleted by this or RFC4306, or RFC7296 or whatever. Updating
document which is effectively already obsoleted, is just wrong...
-- 
kivi...@iki.fi

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

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

[Tero Kivinen]

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
obsoleted protocol defined in the RFC3947. It does define way to
extend things in IKE in similar way than RFC3948 (UDPENCAPS) does. On
the other hand RFC3947 should have been obsoleted when we obsoleted
IKEv1, as that document only defines how to do IKEv1 NAT traversal
negotiation, and the IKEv2 NAT traversal negotation is described in
main IKEv2 RFC (RFC7296).

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

The reason RFC3947 reserved TCP/4500 was that it updated both TCP/4500
and UDP/4500 references from individual user to the RFC3947, so that
IETF will have change control over the ports. I.e., those ports were
allocated before RFC3947 came out, and they were used for several
different non-interoperable versions of the NAT traversals, which then
evolved to the standard version we define in RFC3947. We decided to
reassign both TCP and UDP port 4500 to RFC3947 so it would be clear
for what use they will be used. Also we commonly reserve both TCP and
UDP ports for same number just in case someone defines a way to run
the protocol over other transport protocol in the future...

RFC3947 does not define anything over TCP/4500. Actually RFC3947 does
not define anything over the UDP/4500 either, it is the RFC3948 that
does that. The RFC3947 just says, we use the format defined in the
RFC3948 over the UDP/4500, but is silent about the TCP/4500.

RFC3947 is efficiently obsoleted, as it only defines the way to do NAT
traversal on IKEv1, and IKEv1 is obsoleted and replaced with IKEv2
(originally RFC4306, and now RFC7296). So the RFC3947 should have been
marked as obsoleted by RFC4306. I am not sure if we want to do that in
this late. 

So my proposal is update the IANA port registry for both UDP/4500 and
TCP/4500 as follows:

 Keyword   DecimalDescription  Reference
 ---   ------  -
 ipsec-nat-t   4500/tcp   IPsec NAT-Traversal  [RFC]
 ipsec-nat-t   4500/udp   IPsec NAT-Traversal  [RFC3948], [RFC7296]

(RFC being this RFC).

Note, that the RFC3947 on the 4500/UDP was changed to RFC3948 as the
RFC3948 actually defines the protocol used over the port. RFC3947
defines the IKEv1 negotiation over the UDP port 500 and 4500, but for
IKEv2 this is already defined in the RFC7296.

The RFC3947 could either be left as it is now, or marked as being
obsoleted by this or RFC4306, or RFC7296 or whatever. Updating
document which is effectively already obsoleted, is just wrong...
-- 
kivi...@iki.fi

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

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

[Sandeep Kampati]

Hi All,

small correction

8.  Data model

Data model for the SDP entries: --> it should be"Data model for the 
SPD entries: "

Regards,
Sandeep.k



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