Re: [pcp] Filter handling in PCP.

["Tirumaleswar Reddy (tireddy)" <[e-mail]>]

Hi Suresh,

Please see inline

> -----Original Message-----
> From: Suresh Kumar Vinapamula Venkata [mailto:[e-mail]]
> Sent: Monday, September 16, 2013 11:22 AM
> To: Tirumaleswar Reddy (tireddy); Simon Perreault; [e-mail]
> Subject: RE: [pcp] Filter handling in PCP.
> 
> Hi Tiru,
> 
> Please see inline.
> 
> On Sep 15, 2013, at 4:37 AM, "Tirumaleswar Reddy (tireddy)"
> <[e-mail]> wrote:
> 
> > Hi Suresh,
> >
> > Please see inline.
> >
> >> -----Original Message-----
> >> From: Suresh Kumar Vinapamula Venkata [mailto:[e-mail]]
> >> Sent: Wednesday, September 11, 2013 11:47 AM
> >> To: Tirumaleswar Reddy (tireddy); Simon Perreault; [e-mail]
> >> Subject: Re: [pcp] Filter handling in PCP.
> >>
> >> Hi Tiru,
> >>
> >> Please see inline.
> >>
> >> On 9/9/13 9:21 PM, "Tirumaleswar Reddy (tireddy)" <[e-mail]>
> >> wrote:
> >>
> >>> Hi Suresh,
> >>>
> >>> Please see inline
> >>>
> >>>> -----Original Message-----
> >>>> From: Suresh Kumar Vinapamula Venkata [mailto:[e-mail]]
> >>>> Sent: Friday, September 06, 2013 2:16 AM
> >>>> To: Tirumaleswar Reddy (tireddy); Simon Perreault; [e-mail]
> >>>> Subject: Re: [pcp] Filter handling in PCP.
> >>>>
> >>>>
> >>>>
> >>>> On 9/5/13 12:32 AM, "Tirumaleswar Reddy (tireddy)" <[e-mail]>
> >>>> wrote:
> >>>>
> >>>>>> -----Original Message-----
> >>>>>> From: Simon Perreault [mailto:[e-mail]]
> >>>>>> Sent: Wednesday, September 04, 2013 10:44 AM
> >>>>>> To: [e-mail]
> >>>>>> Subject: Re: [pcp] Filter handling in PCP.
> >>>>>>
> >>>>>> Le 2013-09-04 01:51, Suresh Kumar Vinapamula Venkata a écrit :
> >>>>>>> a) An existing EIM mapping would be transformed to PCP mapping
> >>>>>> through a
> >>>>>>> MAP request.
> >>>>>>> If that MAP request has filters, and if there are already
> >>>> connections
> >>>>>>> associated with that mapping from hosts that are not matching
> >>>> filters,
> >>>>>>> what should be the fate of those connections? I feel those
> >>>> connections
> >>>>>>> are to be torn down.
> >>>>>>
> >>>>>> I'd say it's up to the implementation. I personally would prefer
> >>>>>> existing connections to stay up and new ones to be refused.
> >>>>>>
> >>>>>>> b) RFC recommends that if there has to be change in filters, there
> >>>> has
> >>>>>>> to be a delete followed by addition of new filters. What should be
> >>>> the
> >>>>>>> fate of the connections from IP addresses of old filters? If those
> >>>>>>> connections are deleted there would be disruption in traffic.
> >>>> Suppose
> >>>>>> I
> >>>>>>> am providing a streaming service, and a new user subscribed. I
> >>>> want to
> >>>>>>> add him to the list, but I would not expect that should not result
> >>>> in
> >>>>>>> disruption for others right? If those connections are not deleted,
> >>>> it
> >>>>>>> would continue to allow connections from addresses that are not
> >>>>>> present
> >>>>>>> in new filters but are present in old filters? Consider some one
> >>>>>> stopped
> >>>>>>> subscription.
> >>>>>>
> >>>>>> Again, up to the implementation.
> >>>>>>
> >>>>>>> Also, if we go with delete followed by add, there is a window where
> >>>>>> any
> >>>>>>> external IP address can connect to internal host during delete and
> >>>> add
> >>>>>>> operation. Why can't there be an explicit delete of individual
> >>>>>> filters?
> >>>>>>> This way client may append to the list of IP addresses in filter,
> >>>> and
> >>>>>>> delete IP addresses without disruption of traffic to others.
> >>>>>>
> >>>>>> That actually might be a shortcoming of the RFC. If you feel that use
> >>>>>> case is important to you, you could propose a way to selectively
> >>>> delete
> >>>>>> filters.
> >>>>>>
> >>>>>>> c) If an existing EIM mapping has EIF configured(admin configured),
> >>>>>> and
> >>>>>>> if there is a PCP mapping request for that mapping but with a
> >>>>>> different
> >>>>>>> set of filters disjoint with admin configured filters, what should
> >>>> be
> >>>>>>> the behavior? I feel PCP should override configured filters.
> >>>>>>
> >>>>>> Up to the implementation.
> >>>>>>
> >>>>>>> d) Filtering option gives option to program allowed list. There is
> >>>> no
> >>>>>>> way to configure inverse of it. Suppose I am providing a service to
> >>>>>>> external world, where anyone can access. My system detected
> >>>> someone is
> >>>>>>> attacking, and it should block only that user. It is not easy to
> >>>> block
> >>>>>>> with the existing constructs as defined in the RFC.
> >>>>>
> >>>>> Firewalls already use various techniques like reputation based
> >>>>> black-listing/white-listing (for example reputation based IP address).
> >>>>> Even if PCP client uses MAP without any FILTER option, it does not mean
> >>>>> it can over-ride the Firewall rules which will block traffic from those
> >>>>> black-listed IP addresses. If Firewall detects that some remote peers
> >>>> are
> >>>>> attacking (for example bots) then it will drop the traffic over-riding
> >>>>> the PCP client request to permit traffic.
> >>>>
> >>>> I agree, and I am not expecting firewall black listed addresses to
> >>>> access
> >>>> my service even if I don't have filters.
> >>>
> >>> Ok.
> >>>
> >>>> But, for some reason if I want to deny access to a specific IP address
> >>>> to
> >>>> reach my service, I don't see a way to do it currently.
> >>>> Wouldn't a new option as mentioned above helps here?
> >>>
> >>> It may help, I am trying to understand the use case. Any specific
> >>> applications that you are thinking of - which would be enhanced to use
> >>> PCP, detects attacks from remote peer and informs the PCP-
> >> First thing that comes to my mind here is bit torrent malware. Once
> >> antivirus detects some malware from some existing connection, I may issue
> >> delete PEER delete request to those connections, but if he is persistently
> >> trying, I think there is no way to block currently on CGN. I may block him
> >> at application level, but he would still consume my resources on CGNAT
> >> box.
> >
> > Ok. But what will be the incentive for anti-virus (AV) to apply this black-
> list filtering rule and reduce the resource utilization on CGNAT ?
> > May be the AV would be interested in this new PCP option because it could
> inform the network to block the incoming traffic and thus save some CPU cycles
> in the host itself.
> 
> My understanding of AV is to protect resources of its user, whether the
> resources are local or remote. Locally it can save CPU cycles, and remote
> resource saved is bandwidth.

Ok.

> >
> >>
> >>> controlled Firewall to block traffic from some specific IP addresses. If
> >>> the application determines that specific IP address is attacking, would
> >>> it apply the blocking rule with a global scope (i.e. block all incoming
> >>> traffic from this specific IP address to any device within the network) ?
> >> Application should block it at the IP level. At the connection level
> >> application may issue a delete PEER request right?
> >>
> >>>
> >>> I suspect some problems with this approach:
> >>>
> >>> a)Both legitimate users and attackers could share the same IPv4 address
> >>> because of NAT - How does this rule ensure that legitimate users are not
> >>> penalized ?
> >> Very valid, that is a generic problem with any IP filtering right?
> >
> > But those rules are typically applied based on IPv4 address reputation
> score. The reputation score has to be bad for the incoming traffic from this
> specific IP addresses to be black-listed. It still has the drawback of unable
> to distinguish legitimate users verses attackers. There are other mechanisms
> proposed like http://tools.ietf.org/html/draft-wing-nat-reveal-option-03 which
> uses USER_HINT TCP option for the TCP server to differentiate between the TCP
> clients sharing the same IP address.
> 
> I was not aware of this draft. Thanks for pointing to me. This works only for
> TCP connections only right ?

Yes, it's for TCP connections only.

> 
> >
> >> Shouldn't we have this issue, where a filter is added to grant access to a
> >> specific IP address and that IP address is shared between attacker and
> >> legitimate user.
> >
> > It's usually the application logic to differentiate b/w attacker and
> legitimate user.
> 
> Consider there are two users sharing same NAT IP address and both are
> legitimate users.
> one is infected with virus causing an attack and another is not. How can
> application prevent access to other user ?

In this attack scenario, Application cannot detect that it is downloading a infected file from a legitimate user. Either host AV or network-based Next Gen FW is needed to detect that the file is infected.

> >
> >>> b)Attacker using IPv6 (for example IPv6 privacy addresses) can easily
> >>> change the IP address and by-pass the black-list rule ?
> >> How is filtering done in case of IPv6? Can't we take same approach here ?
> >
> > I am not sure if reputation based IPv6 filtering is possible because large
> amount of available IPv6 address space.
> >
> >>> c)How will the application determine for how long to block the specific
> >>> black-listed IP addresses ?
> >> For the life time of the mapping or till the filter is deleted, which
> >> application may decide.
> >
> > From your example it's the AV which decides to block the IP addresses and
> not the application.
> My understanding is, a corresponding application would be notified when Anti
> spyware detect a spyware activity on a connection.
> > How will the AV know how long to black-list these IP addresses ?
> Can't exponential approach work here? Where a filter is applied for few
> minutes and withdrawn. If attack still observed, filter is reapplied for more
> minutes. The minutes for which filter is applied in each iteration increases
> exponentially.
> Note, I am not expecting a full fledged protection mechanism through filters.
> I understand filters are permeative. But, it does give some level of defense,
> though suboptimal.

Agreed.

-Tiru.

> 
> >
> > -Tiru.
> >
> >>>
> >>> -Tiru.
> >>>
> >>>>
> >>>>>
> >>>>> -Tiru.
> >>>>>
> >>>>>>> I feel we should
> >>>>>>> support inverse msg type(except the mentioned IP address allow any
> >>>>>> one)
> >>>>>>> for filter option. We can define new message constructs, how this
> >>>> can
> >>>>>> be
> >>>>>>> modified, like say another attacker identified. When this option is
> >>>>>>> communicated, all associated flows of that address are to be
> >>>> deleted.
> >>>>>>
> >>>>>> Makes sense. If you feel that this is important, feel free to
> >>>> propose an
> >>>>>> extension.
> >>>>>>
> >>>>>> Just my 2 cents...
> >>>>>>
> >>>>>> Simon
> >>>>>> --
> >>>>>> DTN made easy, lean, and smart --> http://postellation.viagenie.ca
> >>>>>> NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
> >>>>>> STUN/TURN server               --> http://numb.viagenie.ca
> >>>>>
> >>>>> _______________________________________________
> >>>>> pcp mailing list
> >>>>> [e-mail]
> >>>>> https://www.ietf.org/mailman/listinfo/pcp
> >
> >
> >