Subject: [pcp] an idea about REMOTE_PEER_FILTER

From: Francis Dupont <[email-masked]>
Date: Thu, 10 Feb 2011 19:51:03 +0100

We have still some open issues about REMOTE_PEER_FILTER
and as it won't be moved to another document we have
to address them to make the base document complete.

(BTW in base-04 figure 1 28 -> 128)

It seems we agree MAP request with a match-all
(i.e., zero prefix length and remote peer IP address)
REMOTE_PEER_FILTER option should remove all filters.

Now we need a way to remove one filter, ideas:
 - authorize multiple options: the first one
  is a match-all (i.e., a reset),
  followed by all wanted filters.

  As a request is atomic, this can work if
  the number of filters stays small.

 - extend the delete operation to delete
  the filter when there is a filter option.
  Seems a bit fragile, i.e., I prefer the previous one.

 - others?

Note we need a 'too many filters' result code anyway.

Regards

[email-masked]

PS: it is strongly related to the ticket #10.

---

From: Simon Perreault <[email-masked]>
Date: Thu, 10 Feb 2011 14:02:11 -0500

On 2011-02-10 13:51, Francis Dupont wrote:
> and as it won't be moved to another document

PCP would be a leaner and better protocol without it. Why not move it to
a separate document about firewall control?

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

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 10 Feb 2011 12:06:44 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Francis Dupont
> Sent: Thursday, February 10, 2011 10:51 AM
> To: [email-masked]
> Subject: [pcp] an idea about REMOTE_PEER_FILTER
> 

I like that idea.  Here is the text which I believe captures what you
describe above:

8.5.2.  REMOTE_PEER_FILTER

   This Option indicates packet filtering is desired.  The remote peer
   port and remote peer IP Address indicate the permitted remote peer's
   source IP address and port for packets from the Internet.  The remote
   peer prefix length indicates the length of the remote peer's IP
   address that is significant; this allows a single Option to permit an
   entire subnet.  After processing this MAP request and generating a
   successful response, the PCP-controlled device will simply drop
   packets with a source IP address, transport, or port that do not
   match the fields.
      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Reserved   | prefix-length |      Remote Peer Port         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     :                                                               :
     :     Remote Peer IP address (32 bits if MAP4,                  :
     :              1 28 bits if MAP6)                               :
     :                                                               :
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   These fields are described below:

   Reserved:  8 reserved bits, MUST be sent as 0 and MUST be ignored
      when received.

   prefix-length:  indicates how many bits of the IPv4 or IPv6 address
      are relevant for this filter.  The value 0 indicates "no filter",
      and will remove all previous filters.  See below for detail.

   Remote Peer Port:  the port number of the remote peer.  The value 0
      indicates "all ports"

   Remote Peer IP address:  The IP address of the remote peer.

   This Option:

      name: REMOTE_PEER_FILTER

      number: 128

      is valid for OpCodes: MAP4, MAP6

      is included in responses: MUST, if it appeared in the request.

      length: 2 if used with MAP4, 5 if used with MAP6

      may appear in: requests

      maximum occurrences: as many as fit within maximum PCP message
      size

   Because of interactions with dynamic ports this Option MUST only be
   used by a client that is operating a server (that is, using the MAP
   OpCode), as this ensures that no other application will be assigned
   the same ephemeral port for its outgoing connection.  Other use by a
   PCP client is NOT RECOMMENDED and will cause some UNSAF NAT traversal
   mechanisms [RFC3424] to fail where they would have otherwise
   succeeded, breaking other applications running on this same host.

   The prefix-length indicates how many bits of the IPv6 address or IPv4
   address are used for the filter.  For MAP4, a prefix-length of 32
   indicates the entire IPv4 address is used.  For MAP6, a prefix-length
   of 128 indicates the entire IPv6 address is used.  For MAP4 the
   minimum prefix-length value is 0 and the maximum value is 32.  For
   MAP6 the minimum prefix-length value is 0 and the maximum value is
   128.  Values outside those range cause an MALFORMED_OPTION response
   code.

   If multiple occurrences of REMOTE_PEER_FILTER exist, they are
   processed in the same order received.

   To remove all existing filters, the prefix-length 0 is used.

   To change an existing filter, the PCP client sends a MAP request
   containing two REMOTE_PEER_FILTER options, the first option
   containing a prefix-length of 0 (to delete all existing filters) and
   the second containing the new remote peer's IP address and port.  To
   allow an additional remote peer to an existing filtered mapping, a
   new MAP request is sent with the REMOTE_PEER_FILTER.

   The PCP server or the PCP-controlled device is expected to have a
   limit on the number of remote peers it can support.  This limit might
   be as small as one.  If a MAP request would exceed this limit, the
   entire MAP request is rejected with the result code
   EXCESSIVE_FILTERS, and the state on the PCP server is unchanged.

      [Ed. Note: If a filter is created, and minutes later a normal MAP
      refresh occurs, do we want an indication in the response that
      there is some filtering??  Seems useful.  Of course, there might
      be so many filters that we can't list them all in the response.
      So perhaps just an indication?]

-d

---

From: Reinaldo Penno <[email-masked]>
Date: Thu, 10 Feb 2011 16:27:01 -0500

I think most of it is okay. I'm a little uneasy with prefix length 0 meaning
delete if without any prefixes and meaning change with prefixes. These
overloading semantics are usually not very good in the long run.

For example, if I receive a message with prefix length 0 I would ignore the
rest of the message and delete everything. But now, depending on what comes
later in the packet I need to make a decision.

But anyway, if others like it we can go with it.

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 10 Feb 2011 15:31:36 -0800

> From: Reinaldo Penno [mailto:[email-masked]]
> Sent: Thursday, February 10, 2011 1:27 PM
> To: Dan Wing; 'Francis Dupont'; [email-masked]
> Subject: Re: [pcp] an idea about REMOTE_PEER_FILTER
> 

If the prefix length is zero, it really isn't overloading anything --
just like lifetime=0 really isn't overloading anything.

Consider, for example, an IPv4 address with a prefix length of 32.
That means the entire IPv4 address is the filter.  A prefix length
of 24 means only the first 24 bits ("Class C") are part of the
filter.  A prefix length of 0 means that none of the bits are part
of the filter.  That can have only one meaning:  you don't want any
filter.

> rest of the message and delete everything.

The text says the options are processed in order.  Which means if
there are two options, the first doing a delete (prefix-length=0)
and the second adding a filter, then the existing filter(s) are
all removed and replaced with the new filter.

> But now, depending on what comes

"Decision" means it isn't specific enough (that is, the text is
too vague).  I don't see where the server decides anything, or
the meaning is unclear.  If there is something, please point it
out.

-d

---

From: Reinaldo Penno <[email-masked]>
Date: Thu, 10 Feb 2011 18:47:57 -0500

Ohh, this isn't really a 'change' as in an incremental update. This means
that if I want to add to the filter a single subnet I need to insert in the
message a delete plus all the existing subnets and the new subnet.

If I want to delete a subnet it is a similar process.

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 10 Feb 2011 16:21:09 -0800

> Sent: Thursday, February 10, 2011 3:48 PM
> Ohh, this isn't really a 'change' as in an incremental update.

Correct.  Each additional REMOTE_PEER_FILTER adds an additional
permission (remote peer).  So for example if the initial MAP
request does not contain REMOTE_PEER_FILTER, then anything
on the Internet can send traffic.  If the initial MAP request
(or a subsequent MAP request) contains REMOTE_PEER_FILTER,
then all traffic *except* that indicated remote peer is
filtered.  Sending more REMOTE_PEER_FILTERS adds more
remote peers.

> This means
> that if I want to add to the filter a single subnet I need to insert in
> the message a delete plus all the existing subnets and the new subnet.

Correct.

> If I want to delete a subnet it is a similar process.

Correct.

This seems reasonable to me; I don't see a need for a bunch of these
filters, or for them to be changed too often.  If so, we should come
up with a better way to delete them.  But this is pretty straight
forward and provides a reasonable amount of flexibility.

-d

---

From: Paul Selkirk <[email-masked]>
Date: Thu, 17 Feb 2011 18:18:20 +0000

[Sent on behalf of Francis:]

   
   
=> in my proposal I used the argument that the request processing is
atomic, i.e., all or none of the options are processed.
I believe it is the point Reinaldo liked to be clarified.

Regards

PS: in the hairiest case, delete followed by filters, this means it
should be implemented by as a filter list replace (or in two passes).

----------------
And a few thoughts of my own:

Section 5.3 (Options) says options may be encoded in any order, but
does not say anything about processing order.  Section 8.5.2
(REMOTE_PEER_FILTER) is I think the only place where processing order
is discussed.  The very presence of the UNPROCESSED response option in
the spec means that request processing is not atomic in the
all-or-nothing sense, at least as it applies to the entire request, but
it would be good to have this stated clearly.

REMOTE_PEER_FILTER is option #128, which means the "P" bit is set, which
means processing follows the logic in 6.3.1.  If any REMOTE_PEER_FILTER
option fails, there is one UNPROCESSED response option for
REMOTE_PEER_FILTER, which leaves the filter in an ambiguous state, which
I think is the crux of Francis's comment about atomicity - does the
server roll back the filter state, or leave it in the state of the last
successful filter operation?  Is leaving a broken filter acceptable?

Regardless of whether the operation is atomic or not, the server has no
way to indicate which REMOTE_PEER_FILTER request option failed, and the
client has no way to query about the state of filtering, so it can only
delete all filters and try again.

				paul

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 17 Feb 2011 11:26:47 -0800

> Paul Selkirk
> Sent: Thursday, February 17, 2011 10:18 AM
> To: [email-masked]

Ok.  How is the following revised text:

          If multiple occurrences of REMOTE_PEER_FILTER exist in
          the same MAP request, they are processed in the same order
          received, and they MUST all be successfully processed or
          return an error (e.g., MALFORMED_OPTION if one of the
          options was malformed).  As with other PCP errors, returning an
          error causes no state to be changed in the PCP server or in
          the PCP-controlled device.

> should be implemented by as a filter list replace (or in two passes).

I don't see the purpose of a delete (lifetime=0) with the 
REMOTE_PEER_FILTER option.  How about we just prohibit that with
the following new text:

          If a MAP
          request has a lifetime of 0 and contains the
          REMOTE_PEER_FILTER option, the error MALFORMED_OPTION is
          returned.

> does not say anything about processing order.

Added:

  and are processed in the order received

> Section 8.5.2

Added to Section 5.3, "Options":

  If, while processing an option, an error is encountered that causes a
  PCP error response to be generated, the PCP request causes no state
  change in the PCP server or the PCP-controlled device.

> successful filter operation?  Is leaving a broken filter acceptable?

It rolls back.  If the above proposed text doesn't clarify it 
sufficiently, please let me know.

> way to indicate which REMOTE_PEER_FILTER request option failed,

Correct.

> and the

Yep.

-d

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

---

From: Paul Selkirk <[email-masked]>
Date: Thu, 17 Feb 2011 22:36:04 +0000

>           the PCP-controlled device.

Does this say anything that's not covered by the revised section 5.3?

>           REMOTE_PEER_FILTER option, the error MALFORMED_OPTION is

I think he meant "delete filter" (prefix=0), not "delete mapping".
But it's not a bad idea to spell out error conditions.

>   and are processed in the order received

Okay.

>   change in the PCP server or the PCP-controlled device.

Just to clarify, if any part of the request fails, the whole request
fails, and the PCP server rolls back any changes it may have made while
processing the request.

				paul

---

From: Francis Dupont <[email-masked]>
Date: Fri, 18 Feb 2011 01:29:12 +0100

=> oops, I mean delete (prefix length=0) aka reset.

             If a MAP
   
=> yes of course.

Regards