Subject: Re: [sfc] WG LC for draft-ietf-sfc-long-lived-flow-use-cases-01

From: Ramki Krishnan <[email-masked]>
Date: Thu, 22 Jan 2015 05:08:55 +0000

Many thanks for the comments so far; please find an updated version of the draft addressing them.

http://datatracker.ietf.org/doc/draft-ietf-sfc-long-lived-flow-use-cases/

Thanks,
Ramki

From: sfc [mailto:[email-masked]] On Behalf Of Jim Guichard (jguichar)
Sent: Monday, December 15, 2014 7:15 AM
To: [email-masked]
Subject: [sfc] WG LC for draft-ietf-sfc-long-lived-flow-use-cases-01

Dear WG:

This note begins a 2-week WG LC on draft-ietf-sfc-long-lived-flow-use-cases.01.txt.

The document authors have indicated that they have addressed all known comments and that there are no open issues with the current version of the document.

Substantive comments to the list please, editorial comments can go directly to the document editors.

Jim & Thomas

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Fri, 23 Jan 2015 04:27:14 +0000

Hi Ramki,

Comments:

1.

   A transparent firewall may be able to determine that a long-lived

   flow (e.g. video stream, file transfer) has no security issues.

Comment>  In the above line you may want to consider removing "file transfer", FW to inspect files has to act as a L7 proxy and it is not possible to remove itself from the path after the file transfer is initiated.

2.

        a.  The packets which are encrypted at the application layer

          using protocols such as HTTPS [RFC 2660] cannot be decrypted

          and examined further.

Comment> Enterprise Firewalls do act as HTTPS proxy. If HTTPS is used for file transfer and Firewall acts as HTTPS proxy then it cannot by-pass the flow. HTTP/2.0 mandates TLS.

3.

        b.  The packets are from a trusted source.

        c.  The packets are from a trusted application.

Comment> If firewall is white-listing based on destination IP address then the by-pass decision can be made on the SYN packet itself.

4.

     A monitoring element such as a DPI appliance analyzes the new

     flows arriving at the default SecGW device used by a given eNodeB

     device according to criteria such as:

Comment> DPI with HTTP/2.0 will require the ISP to deploy a HTTPS proxy and will result in privacy problems. It may also conflict with the work in other WG like tcpinc with proposals to automatically use TLS without modifying the application layer protocol.

-Tiru

From: sfc [mailto:[email-masked]] On Behalf Of Ramki Krishnan
Sent: Thursday, January 22, 2015 10:39 AM
To: Jim Guichard (jguichar); [email-masked]
Subject: Re: [sfc] WG LC for draft-ietf-sfc-long-lived-flow-use-cases-01

Thanks,
Ramki

From: sfc [mailto:[email-masked]] On Behalf Of Jim Guichard (jguichar)
Sent: Monday, December 15, 2014 7:15 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [sfc] WG LC for draft-ietf-sfc-long-lived-flow-use-cases-01

Dear WG:

Jim & Thomas

---

From: Ramki Krishnan <[email-masked]>
Date: Fri, 23 Jan 2015 05:10:42 +0000

Hi Tiru,

Thanks, please find inline.

Thanks,
Ramki

From: Tirumaleswar Reddy (tireddy) [mailto:[email-masked]]
Sent: Thursday, January 22, 2015 8:27 PM
To: Ramki Krishnan; Jim Guichard (jguichar); [email-masked]
Subject: RE: WG LC for draft-ietf-sfc-long-lived-flow-use-cases-01

Hi Ramki,

Comments:

1.

Ramki: Firewalls do not examine every byte of content. Examining every byte of content is performed by virus scanner, content scanner etc.

2.

          and examined further.

Ramki: HTTPS does not encrypt Layer 2/3/4 headers. As described in the event sequence, SFC manipulation happens at the Layer 2/3/4 level.

3.

Ramki: Agree that this is a good criterion. As we described in the draft, the list of criteria is not exhaustive - it is hard to include every possible case.

4.

Ramki: HTTP/2.0 does not mandate encryption -- http://http2.github.io/faq/#does-http2-require-encryption. We are addressing only the non-encrypted case.

-Tiru

From: sfc [mailto:[email-masked]] On Behalf Of Ramki Krishnan
Sent: Thursday, January 22, 2015 10:39 AM
To: Jim Guichard (jguichar); [email-masked]<mailto:[email-masked]>
Subject: Re: [sfc] WG LC for draft-ietf-sfc-long-lived-flow-use-cases-01

Thanks,
Ramki

Dear WG:

Jim & Thomas

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Fri, 23 Jan 2015 06:01:53 +0000

Inline [TR]

From: Ramki Krishnan [mailto:[email-masked]]
Sent: Friday, January 23, 2015 10:41 AM
To: Tirumaleswar Reddy (tireddy); Jim Guichard (jguichar); [email-masked]
Subject: RE: WG LC for draft-ietf-sfc-long-lived-flow-use-cases-01

Hi Tiru,

Thanks,
Ramki

From: Tirumaleswar Reddy (tireddy) [mailto:[email-masked]]
Sent: Thursday, January 22, 2015 8:27 PM
To: Ramki Krishnan; Jim Guichard (jguichar); [email-masked]<mailto:[email-masked]>
Subject: RE: WG LC for draft-ietf-sfc-long-lived-flow-use-cases-01

Hi Ramki,

Comments:

1.

[TR] Firewalls do have the capability to inspect files to block viruses, malware etc.. FW acts as a proxy, fetches the complete file from the server and scans the file.

2.

          and examined further.

[TR] I may have missed, but did not see any mention in the draft that the service functions do not modify L7 and only manipulate 2/3/4 level. If will be good to explicitly mention that to avoid confusion and also discuss the implication of L4 manipulations with TCP authentication in Security considerations section.

3.

[TR] Okay.

4.

[TR] It may be good to explicitly mention that the use cases deal with only plain text traffic.

-Tiru

Thanks,
Ramki

Dear WG:

Jim & Thomas

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 23 Jan 2015 11:23:46 -0500

Tiru, with regard to the ter firewall, I think the problem is what we 
mean by the word.

Unfortunately, there is no industry or IETF standard definition.
In my experience, people differentiate between firewall functionality, 
intrusion detection functionality, and various forms of malware 
detection / protection functionality.
Some firewall products offer combinations of these features.

In our terms, we are discussing functionality, not product.  Firewall is 
the term that I am familiar with for a device that does statefull or 
stateless filtering based on the L2, L3, and L4-header portions of the 
message.

Is there another term you would like us to use instead of firewall for 
this kind of functionality?

Yours,
Joel

On 1/23/15 1:01 AM, Tirumaleswar Reddy (tireddy) wrote:
> Inline [TR]
>
> *From:*Ramki Krishnan [mailto:[email-masked]]
> *Sent:* Friday, January 23, 2015 10:41 AM
> *To:* Tirumaleswar Reddy (tireddy); Jim Guichard (jguichar); [email-masked]
> *Subject:* RE: WG LC for draft-ietf-sfc-long-lived-flow-use-cases-01
>
> Hi Tiru,
>
> *From:*Tirumaleswar Reddy (tireddy) [mailto:[email-masked]]
> *Sent:* Thursday, January 22, 2015 8:27 PM
> *To:* Ramki Krishnan; Jim Guichard (jguichar); [email-masked]
> <mailto:[email-masked]>
> *Subject:* RE: WG LC for draft-ietf-sfc-long-lived-flow-use-cases-01
>
> Hi Ramki,
>
> Comments:
>
> 1.
>
> Comment>  In the above line you may want to consider removing “file
> transfer”, FW to inspect files has to act as a L7 proxy and it is not
> possible to remove itself from the path after the file transfer is
> initiated.
>
> Ramki: Firewalls do not examine every byte of content. Examining every
> byte of content is performed by virus scanner, content scanner etc.
>
> [TR] Firewalls do have the capability to inspect files to block viruses,
> malware etc.. FW acts as a proxy, fetches the complete file from the
> server and scans the file.
>
> 2.
>
> Comment> Enterprise Firewalls do act as HTTPS proxy. If HTTPS is used
> for file transfer and Firewall acts as HTTPS proxy then it cannot
> by-pass the flow. HTTP/2.0 mandates TLS.
>
> Ramki: HTTPS does not encrypt Layer 2/3/4 headers. As described in the
> event sequence, SFC manipulation happens at the Layer 2/3/4 level.
>
> [TR] I may have missed, but did not see any mention in the draft that
> the service functions do not modify L7 and only manipulate 2/3/4 level.
> If will be good to explicitly mention that to avoid confusion and also
> discuss the implication of L4 manipulations with TCP authentication in
> Security considerations section.
>
> 3.
>
> Comment> If firewall is white-listing based on destination IP address
> then the by-pass decision can be made on the SYN packet itself.
>
> Ramki: Agree that this is a good criterion. As we described in the
> draft, the list of criteria is not exhaustive – it is hard to include
> every possible case.
>
> [TR] Okay.
>
> 4.
>
> Comment> DPI with HTTP/2.0 will require the ISP to deploy a HTTPS proxy
> and will result in privacy problems. It may also conflict with the work
> in other WG like tcpinc with proposals to automatically use TLS without
> modifying the application layer protocol.
>
> Ramki: HTTP/2.0 does not mandate encryption --
> http://http2.github.io/faq/#does-http2-require-encryption. We are
> addressing only the non-encrypted case.
>
> *From:*sfc [mailto:[email-masked]] *On Behalf Of *Ramki Krishnan
> *Sent:* Thursday, January 22, 2015 10:39 AM
> *To:* Jim Guichard (jguichar); [email-masked] <mailto:[email-masked]>
> *Subject:* Re: [sfc] WG LC for draft-ietf-sfc-long-lived-flow-use-cases-01
>
> *From:*sfc [mailto:[email-masked]] *On Behalf Of *Jim Guichard
> (jguichar)
> *Sent:* Monday, December 15, 2014 7:15 AM
> *To:* [email-masked] <mailto:[email-masked]>
> *Subject:* [sfc] WG LC for draft-ietf-sfc-long-lived-flow-use-cases-01
>
> Dear WG:
>
> This note begins a 2-week WG LC on
> draft-ietf-sfc-long-lived-flow-use-cases.01.txt.
>
> The document authors have indicated that they have addressed all known
> comments and that there are no open issues with the current version of
> the document.
>
> _______________________________________________
> sfc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sfc
>

---

From: David Allan I <[email-masked]>
Date: Fri, 23 Jan 2015 16:40:46 +0000

My calendar is up to date...and I'm in San Jose next week.

Dave

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Joel M. Halpern
Sent: Friday, January 23, 2015 8:24 AM
To: Tirumaleswar Reddy (tireddy); Ramki Krishnan; Jim Guichard (jguichar); [email-masked]
Subject: Re: [sfc] WG LC for draft-ietf-sfc-long-lived-flow-use-cases-01

Tiru, with regard to the ter firewall, I think the problem is what we mean by the word.

Unfortunately, there is no industry or IETF standard definition.
In my experience, people differentiate between firewall functionality, intrusion detection functionality, and various forms of malware detection / protection functionality.
Some firewall products offer combinations of these features.

In our terms, we are discussing functionality, not product.  Firewall is the term that I am familiar with for a device that does statefull or stateless filtering based on the L2, L3, and L4-header portions of the message.

Is there another term you would like us to use instead of firewall for this kind of functionality?

Yours,
Joel

On 1/23/15 1:01 AM, Tirumaleswar Reddy (tireddy) wrote:
> Comment>  In the above line you may want to consider removing "file
> transfer", FW to inspect files has to act as a L7 proxy and it is not 
> [TR] Firewalls do have the capability to inspect files to block 
> viruses, malware etc.. FW acts as a proxy, fetches the complete file 
> from the server and scans the file.
>
> 2.
>
> draft, the list of criteria is not exhaustive - it is hard to include 
> every possible case.
>
> [TR] Okay.
>
> 4.
>
> Comment> DPI with HTTP/2.0 will require the ISP to deploy a HTTPS 
> Comment> proxy
> and will result in privacy problems. It may also conflict with the 
> work in other WG like tcpinc with proposals to automatically use TLS 
> without modifying the application layer protocol.
>
> *Subject:* Re: [sfc] WG LC for 
> draft-ietf-sfc-long-lived-flow-use-cases-01
>

---

From: David Allan I <[email-masked]>
Date: Fri, 23 Jan 2015 16:41:53 +0000

Please ignore, outlook hiccup

Dave

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of David Allan I
Sent: Friday, January 23, 2015 8:41 AM
To: Joel M. Halpern; Tirumaleswar Reddy (tireddy); Ramki Krishnan; Jim Guichard (jguichar); [email-masked]
Subject: Re: [sfc] WG LC for draft-ietf-sfc-long-lived-flow-use-cases-01

Dave

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Joel M. Halpern
Sent: Friday, January 23, 2015 8:24 AM
To: Tirumaleswar Reddy (tireddy); Ramki Krishnan; Jim Guichard (jguichar); [email-masked]
Subject: Re: [sfc] WG LC for draft-ietf-sfc-long-lived-flow-use-cases-01

Yours,
Joel

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Fri, 23 Jan 2015 17:24:47 +0000

Hi Joel,

Please see inline

> From: Joel M. Halpern [mailto:[email-masked]]
> Sent: Friday, January 23, 2015 9:54 PM
> intrusion detection functionality, and various forms of malware detection /
> protection functionality.
> In our terms, we are discussing functionality, not product.  Firewall is the
> term that I am familiar with for a device that does statefull or stateless
> filtering based on the L2, L3, and L4-header portions of the message.

Firewalls also operate at Layer 7, you may refer to the terminology explained in https://tools.ietf.org/html/draft-ietf-opsawg-firewalls-01 

> Is there another term you would like us to use instead of firewall for this kind

I guess a note in the draft that the firewall discussed does not operate at Layer 7 would avoid the confusion.

Cheers,
-Tiru

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 23 Jan 2015 12:39:51 -0500

I can live with a parenthetical or sentence indicating that the 
firewalls we are referring to are those operating at layer 3 or 4.  If 
you think it is helpful, we could put in an informative reference to the 
OPSAWG document.  I had not seen that before myself.  Thank you for the 
pointer.

Yours,
Joel

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Fri, 23 Jan 2015 18:17:12 +0000

> Sent: Friday, January 23, 2015 11:10 PM
> I can live with a parenthetical or sentence indicating that the firewalls we are
> referring to are those operating at layer 3 or 4. 

Works for me.

-Tiru

> If you think it is helpful, we
> could put in an informative reference to the OPSAWG document.  I had not
> seen that before myself.  Thank you for the pointer.
> 
> Yours,
> Joel
> 
> >> Subject: Re: [sfc] WG LC for
> >> In my experience, people differentiate between firewall
> >> functionality, intrusion detection functionality, and various forms
> >> of malware detection / protection functionality.
> >> In our terms, we are discussing functionality, not product.  Firewall
> >> is the term that I am familiar with for a device that does statefull
> >> or stateless filtering based on the L2, L3, and L4-header portions of the
> message.
> >
> > Firewalls also operate at Layer 7, you may refer to the terminology
> > explained in
> > https://tools.ietf.org/html/draft-ietf-opsawg-firewalls-01
> >
> >>
> >>> transfer", FW to inspect files has to act as a L7 proxy and it is
> >>> not possible to remove itself from the path after the file transfer
> >>> is initiated.
> >>>
> >>> Ramki: Firewalls do not examine every byte of content. Examining
> >>> every byte of content is performed by virus scanner, content scanner etc.
> >>>
> >>> Comment> Enterprise Firewalls do act as HTTPS proxy. If HTTPS is
> >>> Comment> used
> >>> Ramki: HTTPS does not encrypt Layer 2/3/4 headers. As described in
> >>> the event sequence, SFC manipulation happens at the Layer 2/3/4 level.
> >>>
> >>> [TR] I may have missed, but did not see any mention in the draft
> >>> that the service functions do not modify L7 and only manipulate 2/3/4
> level.
> >>> If will be good to explicitly mention that to avoid confusion and
> >>> also discuss the implication of L4 manipulations with TCP
> >>> authentication in Security considerations section.
> >>>
> >>> 3.
> >>>
> >>> Comment> If firewall is white-listing based on destination IP
> >>> Comment> address
> >>> draft, the list of criteria is not exhaustive - it is hard to
> >>> include every possible case.
> >>>
> >>> [TR] Okay.
> >>>
> >>> 4.
> >>>
> >>> http://datatracker.ietf.org/doc/draft-ietf-sfc-long-lived-flow-use-c
> >>> as
> >>> es/
> >>>
> >>> Thanks,
> >>>
> >>> Ramki
> >>>
> >>> *Subject:* [sfc] WG LC for
> >>> The document authors have indicated that they have addressed all
> >>> known comments and that there are no open issues with the current
> >>> version of the document.
> >>>

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Fri, 23 Jan 2015 18:37:45 +0000

I don't know if the below comment is already discussed (Please ignore if it is not a concern)
The use case in section 4 of http://tools.ietf.org/html/draft-ietf-sfc-long-lived-flow-use-cases-02#section-4 explains having a DPI appliance in ISP may hit a road block in ISEG review because of privacy problem, there are other possible approaches to solve the problem like Application server informing the mobile network that the flow is critical, this way the use case does not have to depend on DPI or limit to just HTTP and can handle HTTPS traffic.  

-Tiru

> >> To: Tirumaleswar Reddy (tireddy); Ramki Krishnan; Jim Guichard
> (jguichar);
> >> [email-masked]
> >> Tiru, with regard to the ter firewall, I think the problem is what we mean
> by
> >> the word.
> >>
> explained in https://tools.ietf.org/html/draft-ietf-opsawg-firewalls-01
> >
> >>
> >> Is there another term you would like us to use instead of firewall for this
> kind
> >> of functionality?
> >
> known

---

From: Ramki Krishnan <[email-masked]>
Date: Sat, 24 Jan 2015 04:10:30 +0000

We will add some clarifying text to address 2) and 4).

Can you please elaborate on "implication of L4 manipulations with TCP authentication"?

1) has been addressed in the other thread with Joel.

Thanks,
Ramki

From: Tirumaleswar Reddy (tireddy) [mailto:[email-masked]]
Sent: Thursday, January 22, 2015 10:02 PM
To: Ramki Krishnan; Jim Guichard (jguichar); [email-masked]
Subject: RE: WG LC for draft-ietf-sfc-long-lived-flow-use-cases-01

Inline [TR]

From: Ramki Krishnan [mailto:[email-masked]]
Sent: Friday, January 23, 2015 10:41 AM
To: Tirumaleswar Reddy (tireddy); Jim Guichard (jguichar); [email-masked]<mailto:[email-masked]>
Subject: RE: WG LC for draft-ietf-sfc-long-lived-flow-use-cases-01

Hi Tiru,

Thanks,
Ramki

Hi Ramki,

Comments:

1.

2.

          and examined further.

3.

[TR] Okay.

4.

-Tiru

Thanks,
Ramki

Dear WG:

Jim & Thomas

---

From: DIEGO LOPEZ GARCIA <[email-masked]>
Date: Sun, 25 Jan 2015 16:57:34 +0000

If I remember well, I suggested to avoid the precise mention to a "DPI" (which is the kind of word that has become taboo in certain circles) in the text of the draft. A simple mention to "a monitoring device", without going beyond in its particular nature or name, should be enough.

Be goode,

--
PLEASE NOTE MY NEW EMAIL ADDRESS
"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: Ramki Krishnan <[email-masked]>
Date: Sun, 25 Jan 2015 19:19:00 +0000

The current text focusses on a monitoring device and DPI is cited as an example of such a device. We could consider removing the DPI example to avoid this confusion.

Thanks,
Ramki

-----Original Message-----
From: DIEGO LOPEZ GARCIA [mailto:[email-masked]] 
Sent: Sunday, January 25, 2015 8:58 AM
To: Tirumaleswar Reddy (tireddy)
Cc: Joel M. Halpern; Ramki Krishnan; Jim Guichard (jguichar); [email-masked]
Subject: Re: [sfc] WG LC for draft-ietf-sfc-long-lived-flow-use-cases-01

Be goode,

On 23 Jan 2015, at 19:37 , Tirumaleswar Reddy (tireddy) <[email-masked]> wrote:

> I don't know if the below comment is already discussed (Please ignore 
> if it is not a concern) The use case in section 4 of http://tools.ietf.org/html/draft-ietf-sfc-long-lived-flow-use-cases-02#section-4 explains having a DPI appliance in ISP may hit a road block in ISEG review because of privacy problem, there are other possible approaches to solve the problem like Application server informing the mobile network that the flow is critical, this way the use case does not have to depend on DPI or limit to just HTTP and can handle HTTPS traffic.
>
> -Tiru
>
>> (jguichar); [email-masked]
>> firewalls we are referring to are those operating at layer 3 or 4.  
>> If you think it is helpful, we could put in an informative reference 
>> to the OPSAWG document.  I had not seen that before myself.  Thank 
>> you for the pointer.
>>
>> Yours,
>> Joel
>>
>>>> of malware detection
>> /
>>>> In our terms, we are discussing functionality, not product.  
>>>> Firewall is the term that I am familiar with for a device that does 
>>>> statefull or stateless filtering based on the L2, L3, and L4-header portions of the message.
>>>
>>> I guess a note in the draft that the firewall discussed does not 
>>> operate at
>> Layer 7 would avoid the confusion.
>>>
>>> Cheers,
>>> -Tiru
>>>
>>>>
>>>> Yours,
>>>> Joel
>>>>
>>>>> *Subject:* RE: WG LC for 
>>>>> *Subject:* RE: WG LC for 
>>>>> Comment>  In the above line you may want to consider removing 
>>>>> Comment> "file
>>>>> not possible to remove itself from the path after the file 
>>>>> transfer is initiated.
>>>>>
>>>>> viruses, malware etc.. FW acts as a proxy, fetches the complete 
>>>>> file from the server and scans the file.
>>>>>
>>>>> 2.
>>>>>
>>>>> that the service functions do not modify L7 and only manipulate 2/3/4 level.
>>>>> work in other WG like tcpinc with proposals to automatically use 
>>>>> TLS without modifying the application layer protocol.
>>>>>
>>>>> http://datatracker.ietf.org/doc/draft-ietf-sfc-long-lived-flow-use
>>>>> -cas
>>>>> es/
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Ramki
>>>>>
>>>>> comments and that there are no open issues with the current 
>>>>> version of the document.
>>>>>

Dr Diego R. Lopez
Telefonica I+D

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Mon, 26 Jan 2015 06:15:05 +0000

Inline [TR]

From: Ramki Krishnan [mailto:[email-masked]]
Sent: Saturday, January 24, 2015 9:41 AM
To: Tirumaleswar Reddy (tireddy); Jim Guichard (jguichar); [email-masked]
Subject: RE: WG LC for draft-ietf-sfc-long-lived-flow-use-cases-01

[TR] TCP authentication is used to protect the TCP segment metadata http://tools.ietf.org/html/rfc5925 (There are discussions going on TCPINC to provide transparent security for TCP connections).

-Tiru

Thanks,
Ramki

Inline [TR]

Hi Tiru,

Thanks,
Ramki

Hi Ramki,

Comments:

1.

2.

          and examined further.

3.

[TR] Okay.

4.

-Tiru

Thanks,
Ramki

Dear WG:

Jim & Thomas