date:20161101

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

2016-11-01 Thread Valery Smyslov

Hi,

 

I have almost the same list of questions as Yoav’s list. But main question is - 

how are you going to ensure that load balancer delivers ESP packets

to the same cluster node where IKE messages that create this ESP SA

were delivered? In other words, load balancer must deliver ESP packets

to the node that can decrypt them, i.e. to the node that has appropriate

keys, i.e. to the node that created this ESP SA, i.e. to the node IKE SA

messages that created that ESP SA were delivered, and this messages definitely 
had 

different UDP ports. If balancer doesn’t know anything about IKE/IPsec and 
looks only 

on UDP ports, then how the above requirement is met? On the other hand,

if you spread ESP keys over all cluster nodes, then why do you bother to

care that load balancer delivers all ESP SA packets to the same node?

 

Regards,

Valery.

 

From: IPsec [mailto:ipsec-boun...@ietf.org] On Behalf Of Yoav Nir
Sent: Tuesday, November 01, 2016 10:31 AM
To: Xuxiaohu
Cc: ipsec@ietf.org
Subject: Re: [IPsec] New Version Notification for 
draft-xu-ipsecme-esp-in-udp-lb-00.txt

 

Hi, Xiaohu

 

A few comments. Actually, they’re more like questions.

 

1.  How are IPsec SAs mapped to UDP pseudo-connections?  Is it a 1:1 
mapping between SPI and source port?
2.  If now, how do you deal with the packet reordering that the load 
balancer will do? IPsec requires ordered or nearly-ordered delivery.
3.  How is this negotiated?  In IKE? Prior agreement?
4.  Why do we need a new port?  What goes wrong if the packets go to port 
4500?

 

Thanks

 

Yoav

On 1 Nov 2016, at 3:45, Xuxiaohu  wrote:

 

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

 

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

Re: [IPsec] FW: New Version Notification fordraft-mglt-ipsecme-implicit-iv-01.txt

2016-11-01 Thread Valery Smyslov

Hi Tobias,

that works for me, thank you.

Regards,
Valery.

> Hey Valery,
> Thanks for the explanation. I added the following statement to the security 
> considerations. Could
you
> please let me know if that resolves your concerns?
> 
>As the IV MUST NOT repeat for one SPI when Counter-Mode ciphers are
>used, Implicit IV as described in this document MUST NOT be used in
>setups with the chance that the Sequence Number overlaps for one SPI.
>Multicast as described in [RFC5374], [RFC6407] and
>[I-D.yeung-g-ikev2] is a prominent example, where many senders share
>one secret and thus one SPI.  Section 3.5 of [RFC6407] explains how
>repetition MAY BE prevented by using a prefix for each group member,
>which could be prefixed to the Sequence Number.  Otherwise, Implicit
>IV MUST NOT be used in multicast scenarios.
> 
> Thanks
> Tobias
> 
> -Ursprüngliche Nachricht-
> Von: Valery Smyslov [mailto:sva...@gmail.com]
> Gesendet: Donnerstag, 20. Oktober 2016 10:16
> An: 'Tobias Guggemos' ; 'Daniel Migault'
> ; 'IPsecME WG' 
> Betreff: RE: [IPsec] FW: New Version Notification 
> fordraft-mglt-ipsecme-implicit-iv-01.txt
> 
> Hi Tobias,
> 
> > Hey Valery,
> > Thanks for the clarification, we'll add this statement in the draft!
> 
> Thank you.
> 
> > Just because I'm interested: For me, this seems to be a general
> > problem for implementing counter
> ciphers
> > in multicast scenarios, regardless of implicit-iv or not.
> > Do you know how the IV is usually chosen in multicast-implementations?
> 
> The Group Controller assigns each sender a unique counter prefix. See Section 
> 3.5 of RFC 6407.
> 
> Regards,
> Valery.
> 
> > Maybe we could add a recommendation in the draft.
> >
> > Thanks
> > Tobias
> >
> >
> >
> > -Ursprüngliche Nachricht-
> > Von: IPsec [mailto:ipsec-boun...@ietf.org] Im Auftrag von Valery
> > Smyslov
> > Gesendet: Montag, 10. Oktober 2016 09:06
> > An: Daniel Migault ; IPsecME WG
> > 
> > Betreff: Re: [IPsec] FW: New Version Notification
> > fordraft-mglt-ipsecme-implicit-iv-01.txt
> >
> > Hi Daniel,
> >
> > I think you should add a text in the Security Considerations that
> > these transforms MUST NOT be
> used in
> > situations where there is a chance that Sequence Numbers repeat. The
> > most prominent example where
> it
> > can happen - multicast ESP SA with multiple senders.
> >
> > Regards,
> > Valery.
> >
> >
> > > Hi,
> > >
> > > Based on the feed backs and the discussions from the previous IETF,
> > > see the updated version of our draft. We believe the document is in
> > > good
> > shape to become a WG document.
> > >
> > > Feel free to support the draft and as usually, comments are welcome!
> > >
> > > BR,
> > > Daniel
> > >
> > > -Original Message-
> > > From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org]
> > > Sent: Saturday, October 08, 2016 7:15 PM
> > > To: Tobias Guggemos ; Yoav Nir
> > > ; Daniel Migault 
> > > Subject: New Version Notification for
> > > draft-mglt-ipsecme-implicit-iv-01.txt
> > >
> > >
> > > A new version of I-D, draft-mglt-ipsecme-implicit-iv-01.txt
> > > has been successfully submitted by Daniel Migault and posted to the
> > > IETF
> > repository.
> > >
> > > Name: draft-mglt-ipsecme-implicit-iv
> > > Revision: 01
> > > Title: Implicit IV for Counter-based Ciphers in IPsec Document date:
> > > 2016-10-08
> > > Group: Individual Submission
> > > Pages: 6
> > > URL:
> > https://www.ietf.org/internet-drafts/draft-mglt-ipsecme-implicit-iv-01
> > .txt
> > > Status:
> > https://datatracker.ietf.org/doc/draft-mglt-ipsecme-implicit-iv/
> > > Htmlized:
> > https://tools.ietf.org/html/draft-mglt-ipsecme-implicit-iv-01
> > > Diff:
> > https://www.ietf.org/rfcdiff?url2=draft-mglt-ipsecme-implicit-iv-01
> > >
> > > Abstract:
> > >   IPsec ESP sends an initialization vector (IV) or nonce in each
> > >   packet, adding 8 or 16 octets.  Some algorithms such as AES-GCM, AES-
> > >   CCM, AES-CTR and ChaCha20-Poly1305 require a unique nonce but do not
> > >   require an unpredictable nonce.  When using such algorithms the
> > >   packet counter value can be used to generate a nonce, saving 8 octets
> > >   per packet.  This document describes how to do this.
> > >
> > >
> > >
> > >
> > > 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
> >
> > ___
> > IPsec mailing list
> > IPsec@ietf.org
> > https://www.ietf.org/mailman/listinfo/ipsec


___

Re: [IPsec] FW: New Version Notification fordraft-mglt-ipsecme-implicit-iv-01.txt

2016-11-01 Thread Tobias Guggemos

Hey Valery,
Thanks for the explanation. I added the following statement to the security
considerations. Could you please let me know if that resolves your concerns?

   As the IV MUST NOT repeat for one SPI when Counter-Mode ciphers are
   used, Implicit IV as described in this document MUST NOT be used in
   setups with the chance that the Sequence Number overlaps for one SPI.
   Multicast as described in [RFC5374], [RFC6407] and
   [I-D.yeung-g-ikev2] is a prominent example, where many senders share
   one secret and thus one SPI.  Section 3.5 of [RFC6407] explains how
   repetition MAY BE prevented by using a prefix for each group member,
   which could be prefixed to the Sequence Number.  Otherwise, Implicit
   IV MUST NOT be used in multicast scenarios.

Thanks 
Tobias

-Ursprüngliche Nachricht-
Von: Valery Smyslov [mailto:sva...@gmail.com] 
Gesendet: Donnerstag, 20. Oktober 2016 10:16
An: 'Tobias Guggemos' ; 'Daniel Migault'
; 'IPsecME WG' 
Betreff: RE: [IPsec] FW: New Version Notification
fordraft-mglt-ipsecme-implicit-iv-01.txt

Hi Tobias,

> Hey Valery,
> Thanks for the clarification, we'll add this statement in the draft!

Thank you.

> Just because I'm interested: For me, this seems to be a general 
> problem for implementing counter
ciphers
> in multicast scenarios, regardless of implicit-iv or not.
> Do you know how the IV is usually chosen in multicast-implementations?

The Group Controller assigns each sender a unique counter prefix. See
Section 3.5 of RFC 6407.

Regards,
Valery.

> Maybe we could add a recommendation in the draft.
> 
> Thanks
> Tobias
> 
> 
> 
> -Ursprüngliche Nachricht-
> Von: IPsec [mailto:ipsec-boun...@ietf.org] Im Auftrag von Valery 
> Smyslov
> Gesendet: Montag, 10. Oktober 2016 09:06
> An: Daniel Migault ; IPsecME WG 
> 
> Betreff: Re: [IPsec] FW: New Version Notification 
> fordraft-mglt-ipsecme-implicit-iv-01.txt
> 
> Hi Daniel,
> 
> I think you should add a text in the Security Considerations that 
> these transforms MUST NOT be
used in
> situations where there is a chance that Sequence Numbers repeat. The 
> most prominent example where
it
> can happen - multicast ESP SA with multiple senders.
> 
> Regards,
> Valery.
> 
> 
> > Hi,
> >
> > Based on the feed backs and the discussions from the previous IETF, 
> > see the updated version of our draft. We believe the document is in 
> > good
> shape to become a WG document.
> >
> > Feel free to support the draft and as usually, comments are welcome!
> >
> > BR,
> > Daniel
> >
> > -Original Message-
> > From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org]
> > Sent: Saturday, October 08, 2016 7:15 PM
> > To: Tobias Guggemos ; Yoav Nir 
> > ; Daniel Migault 
> > Subject: New Version Notification for 
> > draft-mglt-ipsecme-implicit-iv-01.txt
> >
> >
> > A new version of I-D, draft-mglt-ipsecme-implicit-iv-01.txt
> > has been successfully submitted by Daniel Migault and posted to the 
> > IETF
> repository.
> >
> > Name: draft-mglt-ipsecme-implicit-iv
> > Revision: 01
> > Title: Implicit IV for Counter-based Ciphers in IPsec Document date:
> > 2016-10-08
> > Group: Individual Submission
> > Pages: 6
> > URL:
> https://www.ietf.org/internet-drafts/draft-mglt-ipsecme-implicit-iv-01
> .txt
> > Status:
> https://datatracker.ietf.org/doc/draft-mglt-ipsecme-implicit-iv/
> > Htmlized:
> https://tools.ietf.org/html/draft-mglt-ipsecme-implicit-iv-01
> > Diff:
> https://www.ietf.org/rfcdiff?url2=draft-mglt-ipsecme-implicit-iv-01
> >
> > Abstract:
> >   IPsec ESP sends an initialization vector (IV) or nonce in each
> >   packet, adding 8 or 16 octets.  Some algorithms such as AES-GCM, AES-
> >   CCM, AES-CTR and ChaCha20-Poly1305 require a unique nonce but do not
> >   require an unpredictable nonce.  When using such algorithms the
> >   packet counter value can be used to generate a nonce, saving 8 octets
> >   per packet.  This document describes how to do this.
> >
> >
> >
> >
> > 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
> 
> ___
> 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] New Version Notification for draft-xu-ipsecme-esp-in-udp-lb-00.txt

2016-11-01 Thread Yoav Nir

Hi, Xiaohu

A few comments. Actually, they’re more like questions.

How are IPsec SAs mapped to UDP pseudo-connections?  Is it a 1:1 mapping 
between SPI and source port?
If now, how do you deal with the packet reordering that the load balancer will 
do? IPsec requires ordered or nearly-ordered delivery.
How is this negotiated?  In IKE? Prior agreement?
Why do we need a new port?  What goes wrong if the packets go to port 4500?

Thanks

Yoav
> On 1 Nov 2016, at 3:45, Xuxiaohu  wrote:
> 
> 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

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

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

Re: [IPsec] FW: New Version Notification fordraft-mglt-ipsecme-implicit-iv-01.txt

Re: [IPsec] FW: New Version Notification fordraft-mglt-ipsecme-implicit-iv-01.txt

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

4 matches

Site Navigation

Mail list logo

Footer information