wiretapping continues....

Thu Oct 27 18:12:34 UTC 1994

There was no "quiet" admission and no "approval".

This is still very much an open question. However,
Sprint (atleast) will not sit by and do nothing.
We have created potential choke points in the Internet 
architecture and it would be irresponsible of us (as
a community) to not do anything about it.

Given the fact that  ....

a) NAP operators need traffic numbers (preferably a
NSP-NSP matrix but atleast aggregate counts at
small time granularities) to ensure capacity keeps
ahead of demand 

and 

b) there is a *legitimate* concern about security of
data collection mechanisms and privacy, availability of 
collected data,

The questions is "How can we serve both interests?"

I think one scalable solution is for NSPs, which
presumably collect data for their own requirements,
to report on traffic traversing NAPs. Compiling statistics 
across all NSPs at a cross connect point could provide
us with an accurate picture of traffic levels.
NAP providers must be held responsible for ensuring that 
data is protected, even from sister organizations (such as 
Ameritech v/s AADS IP service, or Sprint v/s SprintLink etc.)

Of course, if you don't trust NAP providers themselves,
we have a slightly bigger problem :)-

ATM NAPs today will not allow a central collection point for
network layer stats (per PVC cell counts are presumably 
available). The Sprint NAP will be similarly constrained
when we move to a central FDDI switch.

What is the right threshold between data collection and
privacy/security ? 

			-- Bilal

> 
> 
> > John Scudder then discussed some modeling he and Sue Hares have done 
> > on the projected load at the NAPs. The basic conclusions are that the 
> > FDDI technology (at Sprint) will be saturated sometime next year and 
> > that load-balancing strategies among NSPs across the NAPS is 
> > imperative for the long term viability of the new architecture. John 
> > also expressed concern over the lack of expressed policy for 
> > the collection of statistical data by the NAP operators. All of the 
> > NAP operator are present and stated that they will collect data, but 
> > that there are serious and open questions concerning the privacy of 
> > that data and how to publish it appropriately. John said that 
> > collecting the data was most important. Without the data, there is 
> > no source information from which publication become possible. He said 
> > that MERIT/NSFNET had already tackled these issues. Maybe the 
> > NAP operators can use this previous work as a model to develop their 
> > own policies for publication. 
> >  
> 
> Merit/NSFNet already tackled these issues in an insufficent and unopen manner.
> 
> MarkFedor/ColeLibby from PSI said there was a "quiet" admission that the old 
> methodology was already "approved" for the SPRINT NAP.
> 
> Marty
> 