Subject: Re: [sfc] IBN Path Configuration solution for draft-dolson-sfc-hierarchical-05

From: Dave Dolson <[email-masked]>
Date: Tue, 14 Jun 2016 14:18:03 +0000

Victor,

Yes, I agree this is a good idea. I intend to add it to the list of alternatives in the draft.
I think it is probably the best of the stateful ideas.
I think to the list of benefits we can also add:
- has potential for security advantages in that it may be harder for a sub-domain SF to attack upper-level paths because the upper-level path is obscured by the flow ID, and the flow ID can be validated as it returns.

I intend to update the draft soon including some changes from the other authors.
If anyone on the list has other feed-back, please let me know.

-Dave
P.S. Victor, it doesn’t appear that your request made it to the list. Hopefully this reply does.

From: Victor Vu [mailto:[email-masked]]
Sent: Friday, June 10, 2016 11:16 PM
To: [email-masked]; Dave Dolson
Subject: [sfc] IBN Path Configuration solution for draft-dolson-sfc-hierarchical-05

Hi,

In draft-dolson-sfc-hierarchical-05, there have been 4 method for restoring upper-level SF path when packets exit lower-level domain, each of them has its disadvantage:

1.  Saving SPI and SI in transport-layer flow state => could not work with SFs wich can change 5-tuple (NAT for example)

2.  Pushing SPI and SI into metadata => MD-type 1 has only 4 metadata slots

3.  Using unique lower-level paths per upper-level path coordinates => too many service paths in lower-level domain

4.  Nesting NSH headers, encapsulating the higher-level NSH headers within the lower-level NSH headers => require SFs in the lower-level domain to be able to parse multiple layers of NSH

Therefore, I would like to propose the Flow-stateful/metadata hybrid solution. The basic idea is to make IBN save top-domain flow information (flow-stateful IBN), and assign each flow an “h-sfc flow ID” mapped to its info and store in 1 Mandatory context header. When packet exit sub-domain, get upper-domain’s info back by the h-sfc flow ID and restore it at the service last hop.
In this way:

  *   Upper domain metadata is preserved, and sub-domains can change it just like a SFs does
  *   Does NOT depend on 5-tuple => work well with NAT
  *   Does NOT require all domains have a same metadata scheme
  *   Scalable: could restore any top-domain information, not just service path
  *   Top domain could use full 4 metadata slots, while sub-domains can use up to 3
  *   Does not require any special functionalities from SFs
  *   ID can be used to differentiate H-SFC and non-H-SFC flows
I would like to listen to your opinions.
Thank you very much.

Best regards,

--

--------------------------------------------------------------

Vu Anh Vu (Victor Vu)

DCN Laboratory - School of Electronic Engineering - Soongsil University

Email: [email-masked]<mailto:[email-masked]> / [email-masked]<mailto:[email-masked]>

Phone: (+82)-2-820-0841

Mobile: (+82)-10-9763-0103

Address: 369 Sangdo-ro, Dongjak-gu (06978), Seoul, Korea

[https://ipmcdn.avast.com/images/2016/icons/icon-envelope-tick-round-orange_184x116-v1.png]<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient&utm_term=oa-2322-b>

Virus-free<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient&utm_term=oa-2322-b>

---

From: VictorVu <[email-masked]>
Date: Wed, 15 Jun 2016 11:10:01 +0900

Hi Mr. Dolson,

Yes, that security advantage is a good point.

Another thing is control plane requirements when we use flow-stateful 
IBN. Frankly, a packet should be able to enter sub-domain at a IBN and 
exit at another one. For this, control plane should manage the 
flow-state of all IBNs.

Regards,

P/S: Apparently my other email couldn't send mail to the mailing list. I 
will use this one

On 6/14/16 11:18 PM, Dave Dolson wrote:
> - has potential for security advantages in that it may be harder for a 
> sub-domain SF to attack upper-level paths because the upper-level path 
> is obscured by the flow ID, and the flow ID can be validated as it 
> returns.
>
> *From:*Victor Vu [mailto:[email-masked]]
> *Sent:* Friday, June 10, 2016 11:16 PM
> *To:* [email-masked]; Dave Dolson
> *Subject:* [sfc] IBN Path Configuration solution for 
> draft-dolson-sfc-hierarchical-05
>
> Hi,
>
> In draft-dolson-sfc-hierarchical-05, there have been 4 method for 
> restoring upper-level SF path when packets exit lower-level domain, 
> each of them has its disadvantage:
>
> 1.  Saving SPI and SI in transport-layer flow state => could not work 
> with SFs wich can change 5-tuple (NAT for example)
>
> 3.  Using unique lower-level paths per upper-level path coordinates => 
> too many service paths in lower-level domain
>
> 4.  Nesting NSH headers, encapsulating the higher-level NSH headers 
> within the lower-level NSH headers => require SFs in the lower-level 
> domain to be able to parse multiple layers of NSH
>
> Therefore, I would like to propose the Flow-stateful/metadata hybrid 
> solution. The basic idea is to make IBN save top-domain flow 
> information (flow-stateful IBN), and assign each flow an “h-sfc flow 
> ID” mapped to its info and store in 1 Mandatory context header. When 
> packet exit sub-domain, get upper-domain’s info back by the h-sfc flow 
> ID and restore it at the service last hop.
>
> In this way:
>
> Email:[email-masked] <mailto:[email-masked]>  /[email-masked] <mailto:[email-masked]>
> Phone: (+82)-2-820-0841
> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient&utm_term=oa-2322-b>
>
> 	
>
> Virus-free 
> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient&utm_term=oa-2322-b> 
>
>
>
>
> _______________________________________________
> sfc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sfc

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 14 Jun 2016 22:31:37 -0400

Actually, I would be very cautious about claiming a security advantage. 
I would hate to find that the security folks were demanding we make a 
cryptographically safe metadatum for path identification.

Yours,
Joel

On 6/14/16 10:10 PM, VictorVu wrote:
>> Email: [email-masked] <mailto:[email-masked]> / [email-masked] <mailto:[email-masked]>
>> Phone: (+82)-2-820-0841

---

From: VictorVu <[email-masked]>
Date: Wed, 15 Jun 2016 11:59:32 +0900

Hi Joel,

The idea here is not encrypting path id. In this approach, we give the 
flow a new "sub-domain flow id" instead of encoding directly 
upper-domain service path information into metadata. Therefore, the 
upper-domain information that not necessary for SFs in lower-domain 
could be obscured.

Another point is upper level domain could use this ID to validate the 
packets when they comeback form lower-level domain.

Is it your meaning, Dave?

BRs,

On 6/15/16 11:31 AM, Joel M. Halpern wrote:
> Actually, I would be very cautious about claiming a security 
> advantage. I would hate to find that the security folks were demanding 
> we make a cryptographically safe metadatum for path identification.
>
> Yours,
> Joel
>
>>> Email: [email-masked] <mailto:[email-masked]> / 
>>> [email-masked] <mailto:[email-masked]>
>>> Phone: (+82)-2-820-0841

---

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 14 Jun 2016 23:46:04 -0400

My point is that there is a big gap between "obscured" and "secured".  A 
agree that the upper layer ID is obscured.  I would hesitate to describe 
it as "secured".
I just want to be careful that we don't claim values for an approach 
that will cause us trouble down the road.

I do understand that there is some significant attraction to the 
proposed approach, although it will probably have to wait for 
rechartering for the working group to fully address it.

Yours,
Joel

---

From: Dave Dolson <[email-masked]>
Date: Wed, 15 Jun 2016 03:56:06 +0000

I accept Joel's point. Although there is a small benefit to obscuring the upper-level path, it is not "secure".
Validating packets is probably possible in all of the approaches.
But so far, we've elected to trust all of the service functions.

-Dave

________________________________________
From: sfc [[email-masked]] on behalf of Joel M. Halpern [[email-masked]]
Sent: Tuesday, June 14, 2016 11:46 PM
To: VictorVu; [email-masked]
Subject: Re: [sfc] IBN Path Configuration solution for draft-dolson-sfc-hierarchical-05

Yours,
Joel

---

From: DIEGO LOPEZ GARCIA <[email-masked]>
Date: Sat, 18 Jun 2016 12:55:09 +0000

Hi,

The only possible objection someone could come with is the fact that we are limiting a possible hierarchy recursion to three layers (a fourth one could not use any metadata slots) But I would not say that is something I feel very much concerned about (hence the impersonal “someone” rather than a personal “I”)

Be goode,

On 14 Jun 2016, at 16:18 , Dave Dolson <[email-masked]<mailto:[email-masked]>> wrote:

Victor,

-Dave

From: Victor Vu [mailto:[email-masked]]
Sent: Friday, June 10, 2016 11:16 PM
To: [email-masked]<mailto:[email-masked]>; Dave Dolson
Subject: [sfc] IBN Path Configuration solution for draft-dolson-sfc-hierarchical-05

Hi,

In this way:

Best regards,

--

Vu Anh Vu (Victor Vu)

Phone: (+82)-2-820-0841

_______________________________________________
sfc mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/sfc

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.es/diego.lopez/

e-mail: [email-masked]
Tel:    +34 913 129 041
Mobile: +34 682 051 091
----------------------------------

________________________________

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição

---

From: VictorVu <[email-masked]>
Date: Sun, 19 Jun 2016 01:09:34 +0900

Hi,

Actually, it only requires 1 metadata slot for as many layers as you 
want. Lower-level IBNs simply save upper-level hSFC flow ID in metadata 
and overwrite it. Flow-stateful IBNs can even save all upper-level 
metadata and recover later, so lower-level domains at any layer are free 
to use 3 metadata slots.

Regards,

On 6/18/16 9:55 PM, DIEGO LOPEZ GARCIA wrote:
> Hi,
>
> The only possible objection someone could come with is the fact that 
> we are limiting a possible hierarchy recursion to three layers (a 
> fourth one could not use any metadata slots) But I would not say that 
> is something I feel very much concerned about (hence the impersonal 
> “someone” rather than a personal “I”)
>
> Be goode,
>
>> - has potential for security advantages in that it may be harder for 
>> a sub-domain SF to attack upper-level paths because the upper-level 
>> path is obscured by the flow ID, and the flow ID can be validated as 
>> it returns.
>> *Sent:*Friday, June 10, 2016 11:16 PM
>> *To:[email-masked] <mailto:[email-masked]>; Dave Dolson
>> *Subject:*[sfc] IBN Path Configuration solution for 
>> 3.  Using unique lower-level paths per upper-level path coordinates 
>> => too many service paths in lower-level domain
>>
>> packet exit sub-domain, get upper-domain’s info back by the h-sfc 
>> flow ID and restore it at the service last hop.
>>
>> In this way:
>>
>> [email-masked] <mailto:[email-masked]>
> ------------------------------------------------------------------------
>
> Este mensaje y sus adjuntos se dirigen exclusivamente a su 
> destinatario, puede contener información privilegiada o confidencial y 
> es para uso exclusivo de la persona o entidad de destino. Si no es 
> usted. el destinatario indicado, queda notificado de que la lectura, 
> utilización, divulgación y/o copia sin autorización puede estar 
> prohibida en virtud de la legislación vigente. Si ha recibido este 
> mensaje por error, le rogamos que nos lo comunique inmediatamente por 
> esta misma vía y proceda a su destrucción.
>
> The information contained in this transmission is privileged and 
> confidential information intended only for the use of the individual 
> or entity named above. If the reader of this message is not the 
> intended recipient, you are hereby notified that any dissemination, 
> distribution or copying of this communication is strictly prohibited. 
> If you have received this transmission in error, do not read it. 
> Please immediately reply to the sender that you have received this 
> communication in error and then delete it.
>
> Esta mensagem e seus anexos se dirigem exclusivamente ao seu 
> destinatário, pode conter informação privilegiada ou confidencial e é 
> para uso exclusivo da pessoa ou entidade de destino. Se não é vossa 
> senhoria o destinatário indicado, fica notificado de que a leitura, 
> utilização, divulgação e/ou cópia sem autorização pode estar proibida 
> em virtude da legislação vigente. Se recebeu esta mensagem por erro, 
> rogamos-lhe que nos o comunique imediatamente por esta mesma via e 
> proceda a sua destruição

---

---

From: DIEGO LOPEZ GARCIA <[email-masked]>
Date: Sun, 19 Jun 2016 21:58:35 +0000

Hi,

I see. So the price the pay would be only a metadata slot, what seems quite reasonable.

Be goode,

On 18 Jun 2016, at 18:09 , VictorVu <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

Actually, it only requires 1 metadata slot for as many layers as you want. Lower-level IBNs simply save upper-level hSFC flow ID in metadata and overwrite it. Flow-stateful IBNs can even save all upper-level metadata and recover later, so lower-level domains at any layer are free to use 3 metadata slots.

Regards,

Be goode,

On 14 Jun 2016, at 16:18 , Dave Dolson <<mailto:[email-masked]>[email-masked]<mailto:[email-masked]>> wrote:

Victor,

-Dave

From: Victor Vu [mailto:[email-masked]]
Sent: Friday, June 10, 2016 11:16 PM
To: <mailto:[email-masked]> [email-masked]<mailto:[email-masked]>; Dave Dolson
Subject: [sfc] IBN Path Configuration solution for draft-dolson-sfc-hierarchical-05

Hi,

In this way:

Best regards,

--

Vu Anh Vu (Victor Vu)

Phone: (+82)-2-820-0841

Dr Diego R. Lopez
Telefonica I+D

e-mail: [email-masked]<mailto:[email-masked]>
Tel:    +34 913 129 041
Mobile: +34 682 051 091
----------------------------------

[https://ipmcdn.avast.com/images/2016/icons/icon-envelope-tick-round-orange_184x116-v1.png]<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient&utm_term=oa-2322-a> Virus-free. www.avast.com<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient&utm_term=oa-2322-a>

Dr Diego R. Lopez
Telefonica I+D

---

From: Dave Dolson <[email-masked]>
Date: Wed, 22 Jun 2016 20:20:33 +0000

Victor,
I’m going to add this section. Does it look OK to you?

3.1.5.  Stateful / Metadata Hybrid

   The basic idea of this approach is for the IBN to save upper domain
   encapsulation information such that it can be retrieved by a unique
   identifier, termed an "hSFC Flow ID".  An example ID is shown in
   Table 1.

   +-----------+-----+-----+----------+----------+----------+----------+
   | hSFC Flow | SPI | SI  | Context1 | Context2 | Context3 | Context4 |
   | ID        |     |     |          |          |          |          |
   +-----------+-----+-----+----------+----------+----------+----------+
   | 1         | 45  | 254 | 100      | 2112     | 12345    | 7        |
   +-----------+-----+-----+----------+----------+----------+----------+

     Table 1: Example Mapping of an hSFC Flow ID to Upper-Level Header

   The ID is placed in the metadata in NSH headers of the packet in the
   lower domain, as shown in Figure 4.  When packets exit the lower
   domain, the IBN uses the ID to retrieve the appropriate NSH
   encapsulation for returning the packet to the upper domain.

      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |Ver|O|C|R|R|R|R|R|R|   Length  |  MD-type=0x1  | Next Protocol |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |          Service Path Identifer               | Service Index |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                      hSFC Flow ID                             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                Mandatory Context Header                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                Mandatory Context Header                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                Mandatory Context Header                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

          Figure 4: Storing hSFC Flow ID in lower-level metadata

   Advantages of this approach include:

   o  Does not require state based on 5-tuple, so it works with
      functions that change the IP addresses or ports of a packet such
      as NATs,

   o  Does not require all domains to have the same metadata scheme,

   o  Can be used to restore any upper-domain information, not just
      service path,

   o  The lower domain only requires a single item of metadata
      regardless of the number of items of metadata used in the upper
      domain.  (For MD-Type 1, this leaves 3 slots for use in the lower
      domain.)

   o  No special functionality is required of the SF, other than the
      usual ability to preserve metadata and to apply metadata to
      injected packets.

   Disadvantages include those of other stateful approaches, including
   state timeout and replication mentioned in Section 3.1.1.

   There may be a large number of unique NSH encapsulations to be
   stored, given that the hSFC Flow ID must represent all of the bits in
   the upper-level encapsulation.  This might consume a lot of memory or
   create out-of-memory situations in which IDs cannot be created or old
   IDs are discarded while still in use.

From: sfc [mailto:[email-masked]] On Behalf Of VictorVu
Sent: Saturday, June 18, 2016 12:10 PM
To: DIEGO LOPEZ GARCIA
Cc: [email-masked]
Subject: Re: [sfc] IBN Path Configuration solution for draft-dolson-sfc-hierarchical-05

Hi,

Regards,

Be goode,

Victor,

-Dave

Hi,

Best regards,

--

Vu Anh Vu (Victor Vu)

Phone: (+82)-2-820-0841

Dr Diego R. Lopez
Telefonica I+D

[https://ipmcdn.avast.com/images/2016/icons/icon-envelope-tick-round-orange_184x116-v1.png]<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient&utm_term=oa-2322-a>

Virus-free. www.avast.com<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient&utm_term=oa-2322-a>