Re: [IPsec] Spencer Dawkins' No Objection on charter-ietf-ipsecme-10-00: (with COMMENT)

2016-08-31 Thread Tommy Pauly 

> On Aug 31, 2016, at 3:23 AM, Tero Kivinen  wrote:
> 
> Kathleen Moriarty writes:
 "There have been middle boxes blocking IKE negotiation over UDP. To
 make IKE work in these environments, IKE packets need to be
 encapsulated in a TCP tunnel.
>>> 
>>> 
>>> "In a TCP tunnel" is perhaps a little confusing, as IPinIP or an IPsec
>>> tunnel was not meant. Instead, we meant "encapsulated in TCP".
>> 
>> OK, I am changing this text too, thanks.
>>> 
 The group will define a mechanism to
 tunnel IKE and IPsec over a TCP-based connection. This method is
 intended to be used as a fallback when IKE cannot be negotiated over
 UDP. The group will create a method where IKEv2 and IPsec packets can
 be encapsulated in the TCP connection."
>>> 
>>> 
>>> 
 going for external review, but I'd love to understand better what the
 resulting protocol stack looks like. I get the part about encapsulating
 IKEv2 in TCP, but is encapsulating IPsec in TCP going to give us a
 general-purpose "IP over TCP" mechanism?

In effect, yes: we prefer that IKE/IPSec tunnels are run over UDP for various 
reasons (performance, etc), but having a fallback over TCP allows it to be a 
generic tunneling mechanism over TCP, such that implementations can use this as 
a standardized VPN that works on UDP or TCP, and not need a proprietary 
protocol.

>>> 
>>> 
>>> It will be "ESP over TCP" similar to how we now have "ESP over UDP".
>> 
>> We should be more explicit here, I agree with Spencer.  The IKE part
>> is clear since that's UPD 500.  Would this be transport mode ESP only?
>> If that's the case, how is the following alteration to the text:
>> 
>> The group will define a mechanism to
>> tunnel IKE and IPsec over a TCP-based connection. This method is
>> intended to be used as a fallback when IKE cannot be negotiated over
>> UDP. The group will create a method where IKEv2 and IPsec ESP
>> transport mode packets can
>> be encapsulated in the TCP connection."
>> 
>> Working group: If I've changed the intent too much, please suggest
>> other wording.
> 
> The traffic inside the TCP-based connection is usually ESP tunnel
> mode, not transport mode, so the change you made is limiting it too
> much.
> 
> I.e., this is intended for mobile phones / laptops etc doing VPN
> connection from the hotel to the enterprice vpn gateway and where the
> hotel etc firewall blocks all UDP traffic. So when UDP does not work
> we make TCP connection and encapsulate all IKE and ESP packets to that
> TCP connection. On those cases the VPN gateway usually assigns
> internal IP-address to the mobile device using configuration payloads
> in IKE, and then the mobile device uses tunnel mode ESP to send data
> to the internal enterprice network. 
> 
> So at least remove the "transport mode" and then it should be ok. 

Right. If we would specific any mode specifically, it should specify tunnel 
mode, not transport mode.

The proposed change to the text is fine apart from the specification of the 
mode!

Thanks,
Tommy

> 
> The protocol stack will look like this:
> 
>  Data packet: IKEv2 packet
> 
>  Application data
>  TCP header   IKEv2 packet
>  Inner IP-header  IKEv2 header
>  ESP  Non-ESP Marker
>  Length   Length
>  TCP header   TCP header
>  Outer IP-header  Outer IP-header
> 
> (Of course as this runs over normal TCP connection, the Length ESP +
> Inner IP-header + TCP header + Application data might get splitted to
> multiple actual packets, or there might be multiple inner packets
> inside the same TCP packet).
> 
> This is similar than what we already have when doing UDP encapsulation
> of IPsec (RFC3948):
> 
> 3.4.  Tunnel Mode ESP Encapsulation
> ...
> AFTER APPLYING ESP/UDP
>--
>   IPv4 |new h.| UDP | ESP |orig IP hdr  | |  |   ESP   | ESP|
>|(opts)| Hdr | Hdr |(any options)| TCP | Data | Trailer |Auth|
>--
>   |< encrypted --->|
> |<- authenticated >|
> 
> but instead of "UDP Hdr" we have TCP connection.
> -- 
> kivi...@iki.fi
> 
> ___
> 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] Spencer Dawkins' No Objection on charter-ietf-ipsecme-10-00: (with COMMENT)

2016-08-31 Thread Tero Kivinen 
Kathleen Moriarty writes:
> >> "There have been middle boxes blocking IKE negotiation over UDP. To
> >> make IKE work in these environments, IKE packets need to be
> >> encapsulated in a TCP tunnel.
> >
> >
> > "In a TCP tunnel" is perhaps a little confusing, as IPinIP or an IPsec
> > tunnel was not meant. Instead, we meant "encapsulated in TCP".
> 
> OK, I am changing this text too, thanks.
> >
> >> The group will define a mechanism to
> >> tunnel IKE and IPsec over a TCP-based connection. This method is
> >> intended to be used as a fallback when IKE cannot be negotiated over
> >> UDP. The group will create a method where IKEv2 and IPsec packets can
> >> be encapsulated in the TCP connection."
> >
> >
> >
> >> going for external review, but I'd love to understand better what the
> >> resulting protocol stack looks like. I get the part about encapsulating
> >> IKEv2 in TCP, but is encapsulating IPsec in TCP going to give us a
> >> general-purpose "IP over TCP" mechanism?
> >
> >
> > It will be "ESP over TCP" similar to how we now have "ESP over UDP".
> 
> We should be more explicit here, I agree with Spencer.  The IKE part
> is clear since that's UPD 500.  Would this be transport mode ESP only?
>  If that's the case, how is the following alteration to the text:
> 
> The group will define a mechanism to
> tunnel IKE and IPsec over a TCP-based connection. This method is
> intended to be used as a fallback when IKE cannot be negotiated over
> UDP. The group will create a method where IKEv2 and IPsec ESP
> transport mode packets can
> be encapsulated in the TCP connection."
> 
> Working group: If I've changed the intent too much, please suggest
> other wording.

The traffic inside the TCP-based connection is usually ESP tunnel
mode, not transport mode, so the change you made is limiting it too
much.

I.e., this is intended for mobile phones / laptops etc doing VPN
connection from the hotel to the enterprice vpn gateway and where the
hotel etc firewall blocks all UDP traffic. So when UDP does not work
we make TCP connection and encapsulate all IKE and ESP packets to that
TCP connection. On those cases the VPN gateway usually assigns
internal IP-address to the mobile device using configuration payloads
in IKE, and then the mobile device uses tunnel mode ESP to send data
to the internal enterprice network. 

So at least remove the "transport mode" and then it should be ok. 

The protocol stack will look like this:

  Data packet:  IKEv2 packet

  Application data
  TCP headerIKEv2 packet
  Inner IP-header   IKEv2 header
  ESP   Non-ESP Marker
  LengthLength
  TCP headerTCP header
  Outer IP-header   Outer IP-header

(Of course as this runs over normal TCP connection, the Length ESP +
Inner IP-header + TCP header + Application data might get splitted to
multiple actual packets, or there might be multiple inner packets
inside the same TCP packet).

This is similar than what we already have when doing UDP encapsulation
of IPsec (RFC3948):

3.4.  Tunnel Mode ESP Encapsulation
...
 AFTER APPLYING ESP/UDP
--
   IPv4 |new h.| UDP | ESP |orig IP hdr  | |  |   ESP   | ESP|
|(opts)| Hdr | Hdr |(any options)| TCP | Data | Trailer |Auth|
--
   |< encrypted --->|
 |<- authenticated >|

but instead of "UDP Hdr" we have TCP connection.
-- 
kivi...@iki.fi

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

Re: [IPsec] Spencer Dawkins' No Objection on charter-ietf-ipsecme-10-00: (with COMMENT)

2016-08-30 Thread Kathleen Moriarty 
On Mon, Aug 29, 2016 at 11:28 PM, Paul Wouters  wrote:
> On Mon, 29 Aug 2016, Spencer Dawkins wrote:
>
>> --
>> COMMENT:
>> --
>>
>> This sentence doesn't parse for me - or maybe I just need more security
>> clue?
>>
>> "IKEv1 using shared secret authentication was partially resistance to
>> quantum computers."
>
>
> s/resistance/resistant

Update has been made, thanks.

>
>> I don't object to this text
>>
>> "There have been middle boxes blocking IKE negotiation over UDP. To
>> make IKE work in these environments, IKE packets need to be
>> encapsulated in a TCP tunnel.
>
>
> "In a TCP tunnel" is perhaps a little confusing, as IPinIP or an IPsec
> tunnel was not meant. Instead, we meant "encapsulated in TCP".

OK, I am changing this text too, thanks.
>
>> The group will define a mechanism to
>> tunnel IKE and IPsec over a TCP-based connection. This method is
>> intended to be used as a fallback when IKE cannot be negotiated over
>> UDP. The group will create a method where IKEv2 and IPsec packets can
>> be encapsulated in the TCP connection."
>
>
>
>> going for external review, but I'd love to understand better what the
>> resulting protocol stack looks like. I get the part about encapsulating
>> IKEv2 in TCP, but is encapsulating IPsec in TCP going to give us a
>> general-purpose "IP over TCP" mechanism?
>
>
> It will be "ESP over TCP" similar to how we now have "ESP over UDP".

We should be more explicit here, I agree with Spencer.  The IKE part
is clear since that's UPD 500.  Would this be transport mode ESP only?
 If that's the case, how is the following alteration to the text:

The group will define a mechanism to
tunnel IKE and IPsec over a TCP-based connection. This method is
intended to be used as a fallback when IKE cannot be negotiated over
UDP. The group will create a method where IKEv2 and IPsec ESP
transport mode packets can
be encapsulated in the TCP connection."

Working group: If I've changed the intent too much, please suggest
other wording.

Thanks

>
> Paul
>



-- 

Best regards,
Kathleen

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

Re: [IPsec] Spencer Dawkins' No Objection on charter-ietf-ipsecme-10-00: (with COMMENT)

2016-08-29 Thread Paul Wouters 

On Mon, 29 Aug 2016, Spencer Dawkins wrote:


--
COMMENT:
--

This sentence doesn't parse for me - or maybe I just need more security
clue?

"IKEv1 using shared secret authentication was partially resistance to
quantum computers."


s/resistance/resistant


I don't object to this text

"There have been middle boxes blocking IKE negotiation over UDP. To
make IKE work in these environments, IKE packets need to be
encapsulated in a TCP tunnel.


"In a TCP tunnel" is perhaps a little confusing, as IPinIP or an IPsec
tunnel was not meant. Instead, we meant "encapsulated in TCP".


The group will define a mechanism to
tunnel IKE and IPsec over a TCP-based connection. This method is
intended to be used as a fallback when IKE cannot be negotiated over
UDP. The group will create a method where IKEv2 and IPsec packets can
be encapsulated in the TCP connection."




going for external review, but I'd love to understand better what the
resulting protocol stack looks like. I get the part about encapsulating
IKEv2 in TCP, but is encapsulating IPsec in TCP going to give us a
general-purpose "IP over TCP" mechanism?


It will be "ESP over TCP" similar to how we now have "ESP over UDP".

Paul

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

[IPsec] Spencer Dawkins' No Objection on charter-ietf-ipsecme-10-00: (with COMMENT)

2016-08-29 Thread Spencer Dawkins 
Spencer Dawkins has entered the following ballot position for
charter-ietf-ipsecme-10-00: 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.)



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



--
COMMENT:
--

This sentence doesn't parse for me - or maybe I just need more security
clue?

"IKEv1 using shared secret authentication was partially resistance to
quantum computers."

I don't object to this text 

"There have been middle boxes blocking IKE negotiation over UDP. To
make IKE work in these environments, IKE packets need to be
encapsulated in a TCP tunnel. The group will define a mechanism to
tunnel IKE and IPsec over a TCP-based connection. This method is
intended to be used as a fallback when IKE cannot be negotiated over
UDP. The group will create a method where IKEv2 and IPsec packets can
be encapsulated in the TCP connection."

going for external review, but I'd love to understand better what the
resulting protocol stack looks like. I get the part about encapsulating
IKEv2 in TCP, but is encapsulating IPsec in TCP going to give us a
general-purpose "IP over TCP" mechanism?


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