[IPsec] 转发: New Version Notification for draft-xu-ipsecme-esp-in-udp-lb-00.txt

[Xuxiaohu]

Hi all,

Any comments and suggestions are welcome.

Best regards,
Xiaohu

> -邮件原件-
> 发件人: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org]
> 发送时间: 2016年10月31日 19:15
> 收件人: Xuxiaohu; zhangdacheng; Xialiang (Frank)
> 主题: New Version Notification for draft-xu-ipsecme-esp-in-udp-lb-00.txt
> 
> 
> A new version of I-D, draft-xu-ipsecme-esp-in-udp-lb-00.txt
> has been successfully submitted by Liang Xia and posted to the IETF 
> repository.
> 
> Name: draft-xu-ipsecme-esp-in-udp-lb
> Revision: 00
> Title:Encapsulating IPsec ESP in UDP for Load-balancing
> Document date:2016-10-31
> Group:Individual Submission
> Pages:7
> URL:
> https://www.ietf.org/internet-drafts/draft-xu-ipsecme-esp-in-udp-lb-00.txt
> Status:
> https://datatracker.ietf.org/doc/draft-xu-ipsecme-esp-in-udp-lb/
> Htmlized:   https://tools.ietf.org/html/draft-xu-ipsecme-esp-in-udp-lb-00
> 
> 
> Abstract:
>   IPsec Virtual Private Network (VPN) is widely used by enterprises to
>   interconnect their geographical dispersed branch office locations
>   across IP Wide Area Network (WAN). To fully utilize the bandwidth
>   available in IP WAN, load balancing of traffic between different
>   IPsec VPN sites over Equal Cost Multi-Path (ECMP) and/or Link
>   Aggregation Group (LAG) within IP WAN is attractive to those
>   enterprises deploying IPsec VPN solutions. This document defines a
>   method to encapsulate IPsec Encapsulating Security Payload (ESP)
>   packets inside UDP packets for improving load-balancing of IPsec
>   tunneled traffic. In addition, this encapsulation is also applicable
>   to some special multi-tenant data center network environment where
>   the overlay tunnels need to be secured.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat

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

Re: [IPsec] FW: Quantum Resistance Requirements

[Garcia Morchon O, Oscar]

> I'm very concerned that we don't wind up with insecure Group PSKs as
> we had with IKEv1.

This description does not reduce IKEv2 security - the PPK is used next to IKEv2 
security.
Furthermore, the description can also support pairwise keys.

I had a look at the description, and a later addition of a scheme such as HIMMO 
is straightforward and such scheme can generate all those pairwise keys very 
easily.
Instead of exchanging a PPK identity, you exchange the HIMMO identity that is 
used to generate the pairwise PPKs.
Since the generated keys depend on the exchanged identities, the scheme could 
also provide authentication.
The communication overhead is very small (a few tens of bytes).

-Original Message-
From: IPsec [mailto:ipsec-boun...@ietf.org] On Behalf Of Tero Kivinen
Sent: Monday, October 31, 2016 11:21 AM
To: Michael Richardson
Cc: IPsecme WG (ipsec@ietf.org); Scott Fluhrer (sfluhrer)
Subject: Re: [IPsec] FW: Quantum Resistance Requirements

Michael Richardson writes:
> > - Authentication; if someone with a Quantum Computer can break the DH
> > in real time, do we care if he can act as a man-in-the-middle?  Scott
> > Fluhrer: not important Michael Richardson: important, provided that we
> > don't run into the same issues that IKEv1 PSKs ran into Tommy Pauly:
> > not important Valery Smylsov: this would be nice to have Oscar
> > Garcia-Morchon: this would be nice to have
>
> I'm very concerned that we don't wind up with insecure Group PSKs as
> we had with IKEv1.

As this document is written (or how I think it is written, as I have not yet 
had time to read the latest version), the PPK used to provide to quantum 
resistance is not used in the authentication, there is still normal IKEv2 
authentication step using normal IKEv2 shared secret, or certificates. So even 
if the people would be using group PPK, that would not allow similar issues 
than what happend with IKEv1.

Of course everybody sharing the same PPK will be able to attack other users of 
the same group by just breaking the Diffie-Hellman :-)

On the other hand even if you know the PPK, you cannot do anything without 
breaking the Diffie-Hellman, as it does not allow you do to man-in-the-middle 
without breaking the normal authentication.

So, yes, there is some dangerous things that can happen, but I do not think it 
will be reducing IKEv2 security even if such insecure practices are used 
(except than it will reduce the quantum resistance provided by PPK, if 
everybody knows PPK).
--
kivi...@iki.fi

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


The information contained in this message may be confidential and legally 
protected under applicable law. The message is intended solely for the 
addressee(s). If you are not the intended recipient, you are hereby notified 
that any use, forwarding, dissemination, or reproduction of this message is 
strictly prohibited and may be unlawful. If you are not the intended recipient, 
please contact the sender by return e-mail and destroy all copies of the 
original message.

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

Re: [IPsec] FW: Quantum Resistance Requirements

[Michael Richardson]

Scott Fluhrer (sfluhrer)  wrote:
>> Michael Richardson writes: > > - Authentication; if someone with a
>> Quantum Computer can break the DH > > in real time, do we care if he
>> can act as a man-in-the-middle?  Scott > > Fluhrer: not important
>> Michael Richardson: important, provided that we > > don't run into the
>> same issues that IKEv1 PSKs ran into Tommy Pauly: > > not important
>> Valery Smylsov: this would be nice to have Oscar > > Garcia-Morchon:
>> this would be nice to have
>> >
>> > I'm very concerned that we don't wind up with insecure Group PSKs as
>> > we had with IKEv1.
>> 
>> As this document is written (or how I think it is written, as I have
>> not yet had time to read the latest version), the PPK used to provide
>> to quantum resistance is not used in the authentication, there is
>> still normal IKEv2 authentication step using normal IKEv2 shared
>> secret, or certificates. So even if the people would be using group
>> PPK, that would not allow similar issues than what happend with IKEv1.

> That is correct; we do not replace the existing privacy and
> authentication features; instead, we supplement them by adding the PPK;
> this PPK is designed to add Quantum Resistance; however at the worse
> (e.g. you use the 'MakeMeTastyGoat' PPK), you still have the
> privacy/authentication security found that IKE provides.

Thank you for this clarification.


-- 
]   Never tell me the odds! | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works| network architect  [ 
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails[ 

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

Re: [IPsec] FW: Quantum Resistance Requirements

[Scott Fluhrer (sfluhrer)]

> -Original Message-
> From: Tero Kivinen [mailto:kivi...@iki.fi]
> Sent: Monday, October 31, 2016 11:20 AM
> To: Michael Richardson
> Cc: Scott Fluhrer (sfluhrer); IPsecme WG (ipsec@ietf.org)
> Subject: Re: [IPsec] FW: Quantum Resistance Requirements
> 
> Michael Richardson writes:
> > > - Authentication; if someone with a Quantum Computer can break the
> DH
> > > in real time, do we care if he can act as a man-in-the-middle?  Scott
> > > Fluhrer: not important Michael Richardson: important, provided that
> we
> > > don't run into the same issues that IKEv1 PSKs ran into Tommy Pauly:
> > > not important Valery Smylsov: this would be nice to have Oscar
> > > Garcia-Morchon: this would be nice to have
> >
> > I'm very concerned that we don't wind up with insecure Group PSKs as
> > we had with IKEv1.
> 
> As this document is written (or how I think it is written, as I have not yet 
> had
> time to read the latest version), the PPK used to provide to quantum
> resistance is not used in the authentication, there is still normal IKEv2
> authentication step using normal IKEv2 shared secret, or certificates. So even
> if the people would be using group PPK, that would not allow similar issues
> than what happend with IKEv1.

That is correct; we do not replace the existing privacy and authentication 
features; instead, we supplement them by adding the PPK; this PPK is designed 
to add Quantum Resistance; however at the worse (e.g. you use the 
'MakeMeTastyGoat' PPK), you still have the privacy/authentication security 
found that IKE provides.

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

[IPsec] I-D Action: draft-ietf-ipsecme-tcp-encaps-03.txt

[Tommy Pauly]

Hello,

I’ve posted a new version of the TCP encapsulation draft with the following 
changes:

1. Added a section to explicitly discuss how to fallback from UDP to TCP 
(retransmissions, etc) based on feedback from the charter discussion
2. Explained that this method of encapsulation can be used for any stream 
protocol, and is not TCP specific, based on feedback from the charter discussion
3. Clarified the use of multiple TCP connections for Child SAs, based on Jun 
Hu’s questions

Also, I’m happy to say that we’ve been doing interoperability testing between 
Apple clients and Cisco server for TCP encapsulation. If anyone else has an 
implementation they’d like to try out, please let us know!

Best,
Tommy

> On Oct 31, 2016, at 8:56 AM, internet-dra...@ietf.org wrote:
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the IP Security Maintenance and Extensions of 
> the IETF.
> 
>Title   : TCP Encapsulation of IKE and IPsec Packets
>Authors : Tommy Pauly
>  Samy Touati
>  Ravi Mantha
>   Filename: draft-ietf-ipsecme-tcp-encaps-03.txt
>   Pages   : 20
>   Date: 2016-10-31
> 
> Abstract:
>   This document describes a method to transport IKE and IPsec packets
>   over a TCP connection for traversing network middleboxes that may
>   block IKE negotiation over UDP.  This method, referred to as TCP
>   encapsulation, involves sending both IKE packets for tunnel
>   establishment as well as tunneled packets using ESP over a TCP
>   connection.  This method is intended to be used as a fallback option
>   when IKE cannot be negotiated over UDP.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-ipsecme-tcp-encaps/
> 
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-ipsecme-tcp-encaps-03
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-tcp-encaps-03
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> ___
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec

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

[IPsec] I-D Action: draft-ietf-ipsecme-tcp-encaps-03.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IP Security Maintenance and Extensions of the 
IETF.

Title   : TCP Encapsulation of IKE and IPsec Packets
Authors : Tommy Pauly
  Samy Touati
  Ravi Mantha
Filename: draft-ietf-ipsecme-tcp-encaps-03.txt
Pages   : 20
Date: 2016-10-31

Abstract:
   This document describes a method to transport IKE and IPsec packets
   over a TCP connection for traversing network middleboxes that may
   block IKE negotiation over UDP.  This method, referred to as TCP
   encapsulation, involves sending both IKE packets for tunnel
   establishment as well as tunneled packets using ESP over a TCP
   connection.  This method is intended to be used as a fallback option
   when IKE cannot be negotiated over UDP.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-ipsecme-tcp-encaps/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-ipsecme-tcp-encaps-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-tcp-encaps-03


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

Re: [IPsec] FW: Quantum Resistance Requirements

[Tero Kivinen]

Michael Richardson writes:
> > - Authentication; if someone with a Quantum Computer can break the DH
> > in real time, do we care if he can act as a man-in-the-middle?  Scott
> > Fluhrer: not important Michael Richardson: important, provided that we
> > don't run into the same issues that IKEv1 PSKs ran into Tommy Pauly:
> > not important Valery Smylsov: this would be nice to have Oscar
> > Garcia-Morchon: this would be nice to have
> 
> I'm very concerned that we don't wind up with insecure Group PSKs as we had
> with IKEv1.

As this document is written (or how I think it is written, as I have
not yet had time to read the latest version), the PPK used to provide
to quantum resistance is not used in the authentication, there is
still normal IKEv2 authentication step using normal IKEv2 shared
secret, or certificates. So even if the people would be using group
PPK, that would not allow similar issues than what happend with IKEv1.

Of course everybody sharing the same PPK will be able to attack other
users of the same group by just breaking the Diffie-Hellman :-)

On the other hand even if you know the PPK, you cannot do anything
without breaking the Diffie-Hellman, as it does not allow you do to
man-in-the-middle without breaking the normal authentication.

So, yes, there is some dangerous things that can happen, but I do not
think it will be reducing IKEv2 security even if such insecure
practices are used (except than it will reduce the quantum resistance
provided by PPK, if everybody knows PPK). 
-- 
kivi...@iki.fi

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