Subject: [lmap] security considerations for LMAP

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 27 Feb 2013 18:27:27 +0000

Hi,

I would like to raise one issue which I believe needs more discussions and clarifications as we prepare for the LMAP BOF and this is related to the security aspects of the use cases and the security requirements that we shall need to place on solutions. The use cases I-D (draft-linsner-lmap-use-cases-02) has a void Security Considerations section, and so does draft-boucadair-lmap-considerations-00. This is fine at this point in time but obviously can't stay like this. Only draft-eardley-lmap-framework-01 deals with part of the security aspects but more from the perspective of protecting the measurement information and storage. 

The use cases however seem to raise a few potential concerns related to the information that is being accessed by different entities, who is authorized to collect and what in large-scale measurements. I can see three possible interfaces that can raise such concerns: 

1. The ISP and Multi-Provider use cases mention the need of one provider having visibility and access into the measurements of another provider - to debug specific performance problems, to realize benchmarking and competitor insight, etc. This can be problematic and needs to put in place proper mechanisms of authorization, as different providers may be in different type of relations, they would like to control what information is made available to competitors and none would accept full visibility of its own internal data
2. The ISP-customer use case: Understanding the quality experienced by customers requires deployment of either software or in some scenarios hardware probes at the customers sites or on the edge. This raises similar problems of visibility as in the previous phase, as well as issues related to privacy protection which may be subject to local or regional (for example European) laws and regulations on privacy. 
3. The regulator case: Having regulators gather, store and process broadband traffic information in domains owned by ISPs raises also issues of authorization of access to such information. Hopefully development and enforcement of broadband policies will become part of the regulation and legislation and these details will be worked eventually out, but until they do and even afterwards proper mechanisms need to be in place in order to control authorization and protect information of the different levels of providers. 

Thoughts? Opinions? 

Regards,

Dan

---

From: <[email-masked]>
Date: Thu, 28 Feb 2013 08:29:06 +0100

Dear Dan,

FWIW, there are some security-related items listed in http://tools.ietf.org/html/draft-boucadair-lmap-considerations-00:

   Q10:  How to control access to measurement results?  How to prevent
         revealing measurement results to external parties?
   Q20:  How the system is designed to ensure topology hiding?

And the following ietm on the impact of policies:
   Q16:  How to make sure measurement data accurately reflect the
         network performance and not the policies enforced in that
         network?

At this stage, we have only questions ...

Cheers,
Med 

>-----Message d'origine-----
>De : [email-masked] [mailto:[email-masked]] De 
>la part de Romascanu, Dan (Dan)
>Envoyé : mercredi 27 février 2013 19:27
>À : [email-masked]
>Objet : [lmap] security considerations for LMAP
>
>Hi,
>
>I would like to raise one issue which I believe needs more 
>discussions and clarifications as we prepare for the LMAP BOF 
>and this is related to the security aspects of the use cases 
>and the security requirements that we shall need to place on 
>solutions. The use cases I-D (draft-linsner-lmap-use-cases-02) 
>has a void Security Considerations section, and so does 
>draft-boucadair-lmap-considerations-00. This is fine at this 
>point in time but obviously can't stay like this. Only 
>draft-eardley-lmap-framework-01 deals with part of the 
>security aspects but more from the perspective of protecting 
>the measurement information and storage. 
>
>The use cases however seem to raise a few potential concerns 
>related to the information that is being accessed by different 
>entities, who is authorized to collect and what in large-scale 
>measurements. I can see three possible interfaces that can 
>raise such concerns: 
>
>1. The ISP and Multi-Provider use cases mention the need of 
>one provider having visibility and access into the 
>measurements of another provider - to debug specific 
>performance problems, to realize benchmarking and competitor 
>insight, etc. This can be problematic and needs to put in 
>place proper mechanisms of authorization, as different 
>providers may be in different type of relations, they would 
>like to control what information is made available to 
>competitors and none would accept full visibility of its own 
>internal data
>2. The ISP-customer use case: Understanding the quality 
>experienced by customers requires deployment of either 
>software or in some scenarios hardware probes at the customers 
>sites or on the edge. This raises similar problems of 
>visibility as in the previous phase, as well as issues related 
>to privacy protection which may be subject to local or 
>regional (for example European) laws and regulations on privacy. 
>3. The regulator case: Having regulators gather, store and 
>process broadband traffic information in domains owned by ISPs 
>raises also issues of authorization of access to such 
>information. Hopefully development and enforcement of 
>broadband policies will become part of the regulation and 
>legislation and these details will be worked eventually out, 
>but until they do and even afterwards proper mechanisms need 
>to be in place in order to control authorization and protect 
>information of the different levels of providers. 
>
>Thoughts? Opinions? 
>
>Regards,
>
>Dan
> 
>
>
>
>_______________________________________________
>lmap mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/lmap
>

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 28 Feb 2013 10:55:52 +0000

Hi Mohamed,

Thanks for pointing these. 

A quick mapping of the questions to the three interfaces (use cases) I described in my mail shows: 

Q10 - applies to all use cases
Q20 especially applies to #1 - my experience is that ISPs consider each their own topology and information about it as an asset to protect and keep confidential and would be very reluctant if large-scale measurement would make this information accessible to competitors
Q16 - I confess I understand this one less. I thought measurements would mainly reflect (real) network performance

Regards,

Dan

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Thursday, February 28, 2013 9:29 AM
> To: Romascanu, Dan (Dan); [email-masked]
> Subject: RE: security considerations for LMAP
> 
> Dear Dan,
> 
> FWIW, there are some security-related items listed in
> http://tools.ietf.org/html/draft-boucadair-lmap-considerations-00:
> 
> >De : [email-masked] [mailto:[email-masked]] De la part de
> >Romascanu, Dan (Dan) Envoyé : mercredi 27 février 2013 19:27 À :
> >[email-masked] Objet : [lmap] security considerations for LMAP
> >
> >Hi,
> >
> >I would like to raise one issue which I believe needs more discussions
> >and clarifications as we prepare for the LMAP BOF and this is related
> >to the security aspects of the use cases and the security requirements
> >that we shall need to place on solutions. The use cases I-D
> >(draft-linsner-lmap-use-cases-02)
> >draft-boucadair-lmap-considerations-00. This is fine at this point in
> >time but obviously can't stay like this. Only
> >draft-eardley-lmap-framework-01 deals with part of the security aspects
> >but more from the perspective of protecting the measurement information
> >and storage.
> >
> >The use cases however seem to raise a few potential concerns related to
> >the information that is being accessed by different entities, who is
> >authorized to collect and what in large-scale measurements. I can see
> >three possible interfaces that can raise such concerns:
> >
> >1. The ISP and Multi-Provider use cases mention the need of one
> >provider having visibility and access into the measurements of another
> >provider - to debug specific performance problems, to realize
> >benchmarking and competitor insight, etc. This can be problematic and
> >needs to put in place proper mechanisms of authorization, as different
> >providers may be in different type of relations, they would like to
> >control what information is made available to competitors and none
> >would accept full visibility of its own internal data 2. The
> >ISP-customer use case: Understanding the quality experienced by
> >customers requires deployment of either software or in some scenarios
> >hardware probes at the customers sites or on the edge. This raises
> >similar problems of visibility as in the previous phase, as well as
> >issues related to privacy protection which may be subject to local or
> >3. The regulator case: Having regulators gather, store and process
> >broadband traffic information in domains owned by ISPs raises also
> >issues of authorization of access to such information. Hopefully
> >development and enforcement of broadband policies will become part of
> >the regulation and legislation and these details will be worked
> >eventually out, but until they do and even afterwards proper mechanisms
> >need to be in place in order to control authorization and protect

---

From: <[email-masked]>
Date: Thu, 28 Feb 2013 13:19:23 +0100

Re-,

Please see inline. 

Cheers,
Med 

>De : Romascanu, Dan (Dan) [mailto:[email-masked]] 
>Envoyé : jeudi 28 février 2013 11:56
>À : BOUCADAIR Mohamed OLNC/OLN; [email-masked]
>Objet : RE: security considerations for LMAP
>
>Hi Mohamed,
>
>Q20 especially applies to #1 - my experience is that ISPs 
>consider each their own topology and information about it as 
>an asset to protect and keep confidential and would be very 
>reluctant if large-scale measurement would make this 
>information accessible to competitors

Med: Yes, this is one aspect. 

>Q16 - I confess I understand this one less. I thought 
>measurements would mainly reflect (real) network performance

Med: An example to illustrate the concern raised in Q16 is an LMAP agent not controlled by the provider offering IP connectivity. This IP Network Provider may install filters to discard some traffic (e.g., detect active probe) or to assign high priority to some flows (e.g., service-sensitive data). The outcome of the LMAP measurement requests will hit those filters and therefore won't reflect the actual network performance but will return the outcome of enforcing these policies. A typical example of policies is any CAC installed at the first IP router. 

>discussions
>security aspects

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 28 Feb 2013 12:23:54 +0000

Hi Med,

I got it. Makes sense, although I would point that this concern is not necessarily a security concern, or only a security concern. In a broader context the security requirement would be related to the danger of and protection against the intentional or unintentional mis-configuration of probes, servers or any other entities involved in LMAP. 

Regards,

Dan

> Sent: Thursday, February 28, 2013 2:19 PM
> >De : Romascanu, Dan (Dan) [mailto:[email-masked]] Envoyé : jeudi 28
> >février 2013 11:56 À : BOUCADAIR Mohamed OLNC/OLN; [email-masked] Objet
> >: RE: security considerations for LMAP
> >
> >Hi Mohamed,
> >
> >Q20 especially applies to #1 - my experience is that ISPs consider each
> >their own topology and information about it as an asset to protect and
> >keep confidential and would be very reluctant if large-scale
> >measurement would make this information accessible to competitors
> 
> >Q16 - I confess I understand this one less. I thought measurements
> >would mainly reflect (real) network performance
> 
> Med: An example to illustrate the concern raised in Q16 is an LMAP agent
> not controlled by the provider offering IP connectivity. This IP Network
> Provider may install filters to discard some traffic (e.g., detect
> active probe) or to assign high priority to some flows (e.g., service-
> sensitive data). The outcome of the LMAP measurement requests will hit
> those filters and therefore won't reflect the actual network performance
> but will return the outcome of enforcing these policies. A typical
> example of policies is any CAC installed at the first IP router.
> 
> >
> >Regards,
> >
> >Dan
> >
> >
> >
> >

---

From: "MORTON JR., ALFRED (AL)" <[email-masked]>
Date: Thu, 28 Feb 2013 09:42:42 -0500

Dan and Med,

> > >[Dan] Q16 - I confess I understand this one less. I thought measurements

This question has been the topic of consideration in IPPM literature.
For example:
http://tools.ietf.org/html/rfc2679#section-6

...   The measurements themselves could be harmed by routers giving
   measurement traffic a different priority than "normal" traffic, or by
   an attacker injecting artificial measurement traffic.  If routers can
   recognize measurement traffic and treat it separately, the
   measurements will not reflect actual user traffic.  If an attacker
   injects artificial traffic that is accepted as legitimate, the loss
   rate will be artificially lowered.  Therefore, the measurement
   methodologies SHOULD include appropriate techniques to reduce the
   probability measurement traffic can be distinguished from "normal"
   traffic.  Authentication techniques, such as digital signatures, may
   be used where appropriate to guard against injected traffic attacks.

For more examples, see the Security sections of 

http://tools.ietf.org/html/rfc3432#section-6.3

http://tools.ietf.org/html/rfc4656#page-38

and finally, the latest appreciation of this topic:
http://tools.ietf.org/html/draft-morton-ippm-2330-update-01

There's always some refinement to do, but LMAP work has a reasonable
foundation to stand on in this particular area.

regards,
Al

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Romascanu, Dan (Dan)
> Sent: Thursday, February 28, 2013 7:24 AM
> To: [email-masked]; [email-masked]
> Subject: Re: [lmap] security considerations for LMAP
> 
> Hi Med,
> 
> I got it. Makes sense, although I would point that this concern is not
> necessarily a security concern, or only a security concern. In a broader
> context the security requirement would be related to the danger of and
> protection against the intentional or unintentional mis-configuration of
> probes, servers or any other entities involved in LMAP.
> 
> Regards,
> 
> Dan
> 
> 
> 
>

---

From: <[email-masked]>
Date: Thu, 28 Feb 2013 15:52:10 +0100

Dear Al,

Thanks for the pointers. 

The story may be different for LMAP as the collected data may have some business impact: a customer running an LMAP agent (not controlled by the network provider) may contact the hotline to complain about the quality of the service as measured using an LMAP-based system (because of the measured data not because of the delivered service itself).

Does it make sense to design the system to detect the presence of such policies and return alarms to the user? 
Should LMAP steup procedure include a phase to assess whether collected data is not impacted by installed policies (e.g., using some heuristics)?
Are these considerations in scope or not?

Calling out these considerations in LMAP is useful.

Cheers,
Med 

>De : MORTON JR., ALFRED (AL) [mailto:[email-masked]] 
>Envoyé : jeudi 28 février 2013 15:43
>À : Romascanu, Dan (Dan); BOUCADAIR Mohamed OLNC/OLN; [email-masked]
>Envoyé : jeudi 28
>consider each

---

From: "MORTON JR., ALFRED (AL)" <[email-masked]>
Date: Thu, 28 Feb 2013 10:21:15 -0500

Hi Med,

Business impact for performance measurements is not new.

> [Med said] ...a customer running an LMAP agent (not controlled by the
> network provider) may contact the hotline to complain about the quality of
> the service as measured using an LMAP-based system (because of the
> measured data not because of the delivered service itself).

remove "LMAP" from the sentence above, and you've described something
that happens many times each day, on many different hotlines.

> [Med said] Does it make sense to design the system to detect the presence of such
> policies and return alarms to the user?
> Should LMAP steup procedure include a phase to assess whether collected
> data is not impacted by installed policies (e.g., using some heuristics)?

Both the detection of policies and methods to assess them can be useful,
but the LMAP activity as described in the BoF proposal would look
to others (possibly IPPM) to design the metrics and methods of measurement.
The tests that are actually run might described in a regional characterization
plan, again this plan would be prepared outside the specific LMAP work proposed.

So, yes, possibly, and no (for LMAP as currently described) are the answers, IMO.
> Calling out these considerations in LMAP is useful.

Of course, so the information is not overlooked by others.

hope this helps,
Al

> Sent: Thursday, February 28, 2013 9:52 AM
> To: MORTON JR., ALFRED (AL); Romascanu, Dan (Dan); [email-masked]
> The story may be different for LMAP as the collected data may have some
> business impact: a customer running an LMAP agent (not controlled by the
> network provider) may contact the hotline to complain about the quality of
> the service as measured using an LMAP-based system (because of the
> measured data not because of the delivered service itself).
> 
> Should LMAP steup procedure include a phase to assess whether collected
> data is not impacted by installed policies (e.g., using some heuristics)?