Re: [IPsec] Labeled IPsec options

-Original Message- From: Paul Wouters Sent: Friday, December 13, 2019 6:51 AM To: Hu, Jun (Nokia - US/Mountain View) Cc: ipsec@ietf.org WG ; Sahana Prasad Subject: RE: [IPsec] Labeled IPsec options On Fri, 13 Dec 2019, Hu, Jun (Nokia - US/Mountain View) wrote: >> If you

Re: [IPsec] Labeled IPsec options

In line as [Hu Jun] -Original Message- From: Paul Wouters Sent: Thursday, December 12, 2019 1:25 PM To: Hu, Jun (Nokia - US/Mountain View) Cc: ipsec@ietf.org WG ; Sahana Prasad Subject: Re: [IPsec] Labeled IPsec options On Wed, 11 Dec 2019, Hu, Jun (Nokia - US/Mountain View) wrote

Re: [IPsec] Labeled IPsec options

+1 for option4, +0.5 for option3 One factor to consider is the granularity of label, for me it is per CHILD_SA; option1 is per TS (e.g TS with label and TS without label could be mixed in the same payload), option2 is per TS payload (e.g. you could have TSi with label, TSr without label)

Re: [IPsec] [I2nsf] 答复: using BGP signaling to achieve IPsec Tunnel configuration (draft-hujun-idr-bgp-ipsec): potential conflict with the I2NSF's Controller facilitated IPsec configuration

sub-TLV in my draft) From: Xialiang (Frank, Network Standard & Patent Dept) Sent: Tuesday, April 2, 2019 2:21 AM To: Robert Raszuk Cc: Hu, Jun (Nokia - US/Mountain View) ; Fernando Pereñíguez García ; Linda Dunbar ; Roman Danyliw ; idr wg ; stephane.litkow...@orange.com; i2...@ietf.org;

Re: [IPsec] using BGP signaling to achieve IPsec Tunnel configuration (draft-hujun-idr-bgp-ipsec): potential conflict with the I2NSF's Controller facilitated IPsec configuration

Again, Linda, as discussed with you multiple times, my draft is really about extending current draft-ietf-idr-tunnel-encaps to cover IPsec tunnel and other encryption tunnel like DTLS in next revsion (based on the feedback I got

Re: [IPsec] Fwd: New Version Notification for draft-pwouters-ikev1-ipsec-graveyard-00.txt

The earlier we get rid of IKEv1, the better Just one comment, regarding "IKEv2 has now seen wide deployment and provides a full replacement for all IKEv1 functionality." , I think there is one feature IKEv2 hasn't provided equivalent yet is group key management. Of course, I don't think it is a

Re: [IPsec] Rename IKE_AUX?

I think IKE_SUPP is better compare to what have mentioned -Original Message- From: IPsec On Behalf Of CJ Tjhai Sent: Monday, November 12, 2018 1:29 PM To: tpa...@apple.com Cc: ipsec@ietf.org; Valery Smyslov Subject: Re: [IPsec] Rename IKE_AUX? How about IKE_SUP or IKE_SUPP (for

Re: [IPsec] Fwd: New Version Notification for draft-sprasad-ipsecme-labeled-ipsec-00.txt (fwd)

> -Original Message- > From: Paul Wouters [mailto:p...@nohats.ca] > Sent: Tuesday, March 06, 2018 5:53 PM > To: Hu, Jun (Nokia - US/Mountain View) <jun...@nokia.com> > Cc: ipsec@ietf.org WG <ipsec@ietf.org>; Sahana Prasad > <sahana.prasa...@gmail.com

Re: [IPsec] Fwd: New Version Notification for draft-sprasad-ipsecme-labeled-ipsec-00.txt (fwd)

Some initial questions/comments: 1. security label is defined as opaque data in the draft, but then how would narrowing work in an inter-op way with opaque data? Or should we define the format for some common use cases (like security enforcement, QoS ...) , and adding a sub-type in TS_SECLABEL

Re: [IPsec] Additional charter items 1/4: Responder MOBIKE

+1 > -Original Message- > From: IPsec [mailto:ipsec-boun...@ietf.org] On Behalf Of Paul Wouters > I support further discussion on this item, but I would like the discussion to > focus first on the goal (failover/redundancy) and then look at solutions > (maybe re-using/extending MOBIKE) >

Re: [IPsec] Additional charter items 3/4: Labeled IPsec

I am also interested in this, since currently there is no good way to identify a CHILD_SA, current traffic selector is too cumbersome to be used as identifier, and in some cases can't be used as a consistent id; for example there are two types of traffic (same protocol/port, but different

Re: [IPsec] Agenda for IETF 100

> -Original Message- > From: Paul Wouters [mailto:p...@nohats.ca] > Sent: Saturday, October 28, 2017 10:28 PM > To: Hu, Jun (Nokia - US/Mountain View) <jun...@nokia.com> > Cc: Valery Smyslov <sva...@gmail.com>; 'Tero Kivinen' <kivi...@iki.fi>; > ipsec@ie

Re: [IPsec] Agenda for IETF 100

> -Original Message- > From: Valery Smyslov [mailto:sva...@gmail.com] > > 1. Develop load sharing cluster solution for IKEv2/IPsec. The possible > > charter > > text: > > > > MOBIKE protocol [RFC4555] is used to move existing IKE/IPsec SA from > > one IP address to another. However, in

Re: [IPsec] Agenda for IETF 100

> From: IPsec [mailto:ipsec-boun...@ietf.org] On Behalf Of Valery Smyslov > 1. Develop load sharing cluster solution for IKEv2/IPsec. The possible charter > text: > > MOBIKE protocol [RFC4555] is used to move existing > IKE/IPsec SA from one IP address to another. However, > in

Re: [IPsec] Ben Campbell's Yes on draft-ietf-ipsecme-rfc7321bis-05: (with COMMENT)

A very real use case is OSPFv3 authentication (RFC 4552), all major router vendor supports OSPFv3 implement that, and it is deployed around world; Plus I don't see any realistic alternative for the use case > -Original Message- > From: IPsec [mailto:ipsec-boun...@ietf.org] On Behalf Of >