Subject: [Rtg-dt-encap-considerations] Thu agenda plus WebEx for Encap team

From: Erik Nordmark <[email-masked]>
Date: Tue, 09 Dec 2014 14:05:54 -0800

Let's switch from jitsi to webex starting this week. Pat has setup a 
meeting (attached). We should try to remember to record them (so that if 
you miss a meeting you can go back and listen).

For Thursday I think we should talk a bit more about OAM's intersection 
with the encap.
It makes sense for us to review the OAM discussion and drafts before 
then, and we already have some thoughts about OAM in the google doc.

Any other agenda items?
We should tee up a discussion about security. Tom volunteered to think 
about this. I think Alia also has a security person standing by. If we 
could have something written up first then we can have a focused 
security discussion with that person (following the same approach as we 
did with David last week.)

Regards,
    Erik

-------- Forwarded Message --------
Subject: 	WebEx for Encap team
Date: 	Tue, 9 Dec 2014 21:38:32 +0000
From: 	Pat Thaler <[email-masked]>
To: 	'Erik Nordmark' <[email-masked]>, Tom Herbert 
<[email-masked]>, [email-masked] <[email-masked]>, 
[email-masked] <[email-masked]>, 
[email-masked] <[email-masked]>, Erik Nordmark 
<[email-masked]>, Pat Thaler <[email-masked]>, Jon Hudson 
<[email-masked]>, [email-masked] <[email-masked]>

---

From: Tom Herbert <[email-masked]>
Date: Tue, 9 Dec 2014 14:37:16 -0800

On Tue, Dec 9, 2014 at 2:05 PM, Erik Nordmark <[email-masked]> wrote:

> It makes sense for us to review the OAM discussion and drafts before then,
> and we already have some thoughts about OAM in the google doc.
>
> Any other agenda items?
> could have something written up first then we can have a focused security
> discussion with that person (following the same approach as we did with
> David last week.)
>
> I added a couple of paragraphs on security to the document. Feel free to
comment!

Tom

> Regards,
>    Erik
>
> -------- Forwarded Message --------  Subject: WebEx for Encap team  Date: Tue,
> 9 Dec 2014 21:38:32 +0000  From: Pat Thaler <[email-masked]>
> <[email-masked]>  To: 'Erik Nordmark' <[email-masked]>
> <[email-masked]>, Tom Herbert <[email-masked]>
> <[email-masked]>, [email-masked] <[email-masked]>
> <[email-masked]>, [email-masked] <[email-masked]>
> <[email-masked]>, [email-masked]
> <[email-masked]> <[email-masked]>, Erik Nordmark
> <[email-masked]> <[email-masked]>, Pat Thaler
> <[email-masked]> <[email-masked]>, Jon Hudson
> <[email-masked]> <[email-masked]>, [email-masked]
> <[email-masked]> <[email-masked]>
>
>
>
>
> _______________________________________________
> Rtg-dt-encap-considerations mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtg-dt-encap-considerations
>
>

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 09 Dec 2014 21:34:40 -0800

Thanks for the security text. I added some comments.

It makes sense to talk about this on Thursday. It makes sense to me to 
think about
  - do we have a good description of the threats and associated assumptions?
  - is there a set of questions we should ask a security expert?

And stating the obvious, the security functionality is likely to be 
optional to use.

    Erik

On 12/9/14 2:37 PM, Tom Herbert wrote:
>
>
> On Tue, Dec 9, 2014 at 2:05 PM, Erik Nordmark <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>
>     Let's switch from jitsi to webex starting this week. Pat has setup
>     a meeting (attached). We should try to remember to record them (so
>     that if you miss a meeting you can go back and listen).
>
>     For Thursday I think we should talk a bit more about OAM's
>     intersection with the encap.
>     It makes sense for us to review the OAM discussion and drafts
>     before then, and we already have some thoughts about OAM in the
>     google doc.
>
>     Any other agenda items?
>     We should tee up a discussion about security. Tom volunteered to
>     think about this. I think Alia also has a security person standing
>     by. If we could have something written up first then we can have a
>     focused security discussion with that person (following the same
>     approach as we did with David last week.)
>
> I added a couple of paragraphs on security to the document. Feel free 
> to comment!
>
> Tom
>
>     Regards,
>        Erik
>
>     <mailto:[email-masked]>
>     To: 	'Erik Nordmark' <[email-masked]>
>     <mailto:[email-masked]>, Tom Herbert <[email-masked]>
>     <mailto:[email-masked]>, [email-masked]
>     <mailto:[email-masked]> <[email-masked]>
>     <mailto:[email-masked]>, [email-masked]
>     <mailto:[email-masked]> <[email-masked]>
>     <mailto:[email-masked]>, [email-masked]
>     <mailto:[email-masked]> <[email-masked]>
>     <mailto:[email-masked]>, Erik Nordmark
>     <[email-masked]> <mailto:[email-masked]>, Pat Thaler
>     <[email-masked]> <mailto:[email-masked]>, Jon Hudson
>     <[email-masked]> <mailto:[email-masked]>,
>     [email-masked] <mailto:[email-masked]> <[email-masked]>
>     <mailto:[email-masked]>
>
>
>
>
>
>
>     <mailto:[email-masked]>

---

From: Tom Herbert <[email-masked]>
Date: Wed, 10 Dec 2014 13:34:23 -0800

>  - do we have a good description of the threats and associated assumptions?

I don't have anything specific on the threats, but I do believe that once
we allowed 3rd party VMs within a data center the risks increased
substantially. The model of a security perimeter around the data center
network is also less relevant these days. The other difficulty is trying to
extrapolate how security requirements will evolve during the lifetime of
the encap protocol.

>
> 1) What aspects do we need to consider, what scope should we addressed?
2) What is sufficient security?
3) How do we expect security threats and therefore defenses will need to
evolve overtime?
4) What can we leverage or is redundant to other mechanisms?
5) What are relevant security issues w.r.t. cloud and virtualization
6) Any guidance on DOS attacks  in this context?

> But hopefully highly encouraged! IMO, security concerns are still one
reason to avoid these cloud, securing the network at the encap level is one
part of a larger picture to make cloud secure.

Tom

   Erik
>> -------- Forwarded Message --------  Subject: WebEx for Encap team  Date:
>> Tue, 9 Dec 2014 21:38:32 +0000  From: Pat Thaler <[email-masked]>

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 10 Dec 2014 15:39:08 -0800

On 12/10/14 1:34 PM, Tom Herbert wrote:
>
>
> On Tue, Dec 9, 2014 at 9:34 PM, Erik Nordmark <[email-masked] 
>     It makes sense to talk about this on Thursday. It makes sense to
>     me to think about
> I don't have anything specific on the threats, but I do believe that 
> once we allowed 3rd party VMs within a data center the risks increased 
> substantially. The model of a security perimeter around the data 
> center network is also less relevant these days. The other difficulty 
> is trying to extrapolate how security requirements will evolve during 
> the lifetime of the encap protocol.
For the time being it makes sense adding those questions to the 
document. (I plan to share the document once we have a security expert 
that we can consult with.)
> 3) How do we expect security threats and therefore defenses will need 
> to evolve overtime?

Ditto.

>     And stating the obvious, the security functionality is likely to
>     be optional to use.
>
> reason to avoid these cloud, securing the network at the encap level 
> is one part of a larger picture to make cloud secure.

It might make sense to preface the security discussion with the 
observation currently deployed encaps (MPLS, Vxlan) do not have any 
explicit support for security, and that we see a need to be able to 
introduce better support based on deployment considerations.
(FWIW In other security discussions in the past we've ended up with RFCs 
saying "mandatory to implement" but optional to enable in any particular 
environment.)

    Erik

>>         Let's switch from jitsi to webex starting this week. Pat has
>>         setup a meeting (attached). We should try to remember to
>>         record them (so that if you miss a meeting you can go back
>>         and listen).
>>
>>         before then, and we already have some thoughts about OAM in
>>         the google doc.
>>
>>         Any other agenda items?
>>         We should tee up a discussion about security. Tom volunteered
>>         to think about this. I think Alia also has a security person
>>         standing by. If we could have something written up first then
>>         we can have a focused security discussion with that person
>>         (following the same approach as we did with David last week.)
>>
>>     I added a couple of paragraphs on security to the document. Feel
>>     free to comment!
>>
>>     Tom
>>
>>         Regards,
>>            Erik
>>
>>         <mailto:[email-masked]>, Tom Herbert
>>         <[email-masked]> <mailto:[email-masked]>,
>>         [email-masked] <mailto:[email-masked]>
>>         <[email-masked]> <mailto:[email-masked]>,
>>         [email-masked] <mailto:[email-masked]>
>>         <[email-masked]> <mailto:[email-masked]>,
>>         [email-masked] <mailto:[email-masked]>
>>         <[email-masked]>
>>         <[email-masked]> <mailto:[email-masked]>, Jon
>>         Hudson <[email-masked]> <mailto:[email-masked]>,
>>         [email-masked] <mailto:[email-masked]>
>>         <[email-masked]> <mailto:[email-masked]>
>>
>>
>>
>>
>>
>>

---

From: Albert Tian <[email-masked]>
Date: Thu, 11 Dec 2014 10:16:31 +0000

Hi Erik

Unfortunately I will not be able to join tomorrow’s (Thursday) discussion due to scheduling conflicts. I’ll catch up with you and the team later. Some of my thoughts on security inlined.

Thanks,
Albert

On 12/10/14, 3:39 PM, "Erik Nordmark" <[email-masked]<mailto:[email-masked]>> wrote:

On Tue, Dec 9, 2014 at 9:34 PM, Erik Nordmark <[email-masked]<mailto:[email-masked]>
<mailto:[email-masked]>> wrote:

     It makes sense to talk about this on Thursday. It makes sense to
     me to think about
      - do we have a good description of the threats and associated
     assumptions?

I don't have anything specific on the threats, but I do believe that
once we allowed 3rd party VMs within a data center the risks increased
substantially. The model of a security perimeter around the data
center network is also less relevant these days.

[Albert] Shouldn’t 3rd party VMs be put under some kind of “quarantine”? Encap could play a role to help create these compartments to isolate and manage the threats.

The other difficulty

[Albert] great question, we need a crystal ball though :-)

[Albert] Threat analysis should probably among the initial things to do. In the encap context, IMHO we need to focus on the new threats that we brought along with a given encap. In particular the trust model between the encapsulator, the decapsulator, and the transit nodes. (We need to start develop our terminology to describe our problems/questions precisely.)

Tom has identified a major problem when the attacker is pretending to be the encapsulator. The consequences are multi-folds:
1. The decapsulator may take the wrong actions based on the malicious encap
2. The transit nodes may take the wrong actions based on the malicious encap

I would say a few words about the attack on transit nodes as they are not covered by Tom’s text.

In many cases the networking encap influences the forwarding of the traffic. Malicious encap can cause packets to be sent onto incorrect directions.

  1.  DoS attack could be one of the consequences if many packets can be directed towards a particular direction/destination.
  2.  New security exposure could be another consequence, as previously inaccessible nodes may become accessible to attackers, due influence of malicious encap.
  3.  if encap is capable of causing replication, which is true in BIER’s case, amplification attack could also be a consequence: malicious BIER encap with all bits set can cause a single packet to be replicated 256 times or more.

We also need to look at the new threats from a compromised transit nodes as well as compromised decapsulator.

Some of the encaps are required to be efficient, especially the lower layer ones; therefore they may not be able to afford some of the more expensive solutions, in particular not on the transit nodes. We may not be able to afford security at every layer. There are cases we may have to look at layers either above or below to provide the solution.
[/Albert]

Ditto.

[Albert] Good observation. We should discuss under what circumstances encap can get away with no security mechanisms :-). IMHO MPLS has largely been deployed within a security perimeter: a service providers backbone for example. MPLS encap are not accepted on links coming from outside the perimeter. Within the perimeter, if an attacker can access to the MPLS encap, it can probably access whatever the encap that was used before (IP/Ether/ATM etc), so MPLS encap did not bring significant new risks within the perimeter. [/Albert]

    Erik

Tom

        Erik

     On Tue, Dec 9, 2014 at 2:05 PM, Erik Nordmark <[email-masked]<mailto:[email-masked]>
     <mailto:[email-masked]>> wrote:

         Any other agenda items?

     Tom

         Regards,
            Erik

         -------- Forwarded Message --------
         Subject: WebEx for Encap team
         Date: Tue, 9 Dec 2014 21:38:32 +0000
         From: Pat Thaler <[email-masked]<mailto:[email-masked]>>
         <mailto:[email-masked]>
         To: 'Erik Nordmark' <[email-masked]<mailto:[email-masked]>>
         <mailto:[email-masked]>, Tom Herbert
         <[email-masked]<mailto:[email-masked]>> <mailto:[email-masked]>,
         [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>
         <[email-masked]<mailto:[email-masked]>> <mailto:[email-masked]>,
         [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>
         <[email-masked]<mailto:[email-masked]>> <mailto:[email-masked]>,
         [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>
         <[email-masked]<mailto:[email-masked]>>
         <mailto:[email-masked]>, Erik Nordmark
         <[email-masked]<mailto:[email-masked]>> <mailto:[email-masked]>, Pat Thaler
         <[email-masked]<mailto:[email-masked]>> <mailto:[email-masked]>, Jon
         Hudson <[email-masked]<mailto:[email-masked]>> <mailto:[email-masked]>,
         [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>
         <[email-masked]<mailto:[email-masked]>> <mailto:[email-masked]>

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

_______________________________________________
Rtg-dt-encap-considerations mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rtg-dt-encap-considerations

_______________________________________________
Rtg-dt-encap-considerations mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rtg-dt-encap-considerations