Subject: Re: [lmap] About draft-schulzrinne-lmap-requirements-00

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 5 Nov 2012 00:28:22 +0000

Picking up some random short comments:

For the parameter retrieval, there is an authentication problem - the client (consumer) generally presumably has legitimate access to its own network parameters, but the ISP has no way to validate a third party and ISPs aren't likely to just answer a random query for "Hi, what's the nominal speed for customer 1.2.3.4?". This isn't as much of a problem if the third party is a national regulatory agency (identification for NATed customers may be), but is a serious issue if it's a private third-party entity chosen by the end user. Thus, I believe that end system access to this data is required for simplicity and functionality, even if others should also have (authenticated) access to the data.

On NATs, for most active measurements, these are inside-out, so this may not require much NAT or firewall interaction. I'm also rather worried about giving a measurement client authority to open up firewalls - this can be used for mischief. Plus, I'd imagine that we would use any existing NAT/firewall control mechanism for this, rather than building a new one.

Henning

________________________________________
From: [email-masked] [[email-masked]] on behalf of Al Morton [[email-masked]]
Sent: Wednesday, September 26, 2012 9:34 AM
To: Robert Kisteleki; [email-masked]
Subject: Re: [lmap] About draft-schulzrinne-lmap-requirements-00

Hi Robert,

The details of network parameters would be known at
other testing entities, but not the edge client/agent.

But the requirement to open the firewall and establish NAT state falls
to the edge client/agent. That's a new wrinkle and needs to be sorted-out
with the rest of the details.

regards,
Al

_______________________________________________
lmap mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/lmap