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: 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.

> 
> >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.

> 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.

> >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.
How will the AV know how long to black-list these IP addresses ?

-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
> >> >
> >> >
> >>
> >
> >
> >
>