Subject: [pcp] When a single mapping is too large to fit in a PCP GET/NEXT response

From: Simon Perreault <[email-masked]>
Date: Wed, 20 Apr 2011 15:15:38 -0400

Hi,

>From draft-boucadair-pcp-failure-01 section 4.6:

   o  if the NEXT Option in the request is an END one, the first mapping
      of the list is returned in an only NEXT option, marked END if the
      list contains only this mapping, marked MORE otherwise.

   o  if the NEXT option in the request is a MORE one, as many as can
      fit mappings are returned in order in the response, marked as MORE
      but if the whole list can be returned the last is marked END.

   "Returned" means to include required options when they are defined
   for a mapping: if the mapping M has 3 REMOTE_PEER_FILTERs and the
   REMOTE_PEER_FILTER code was in the request NEXT, the NEXT carrying M
   will get the 3 REMOTE_PEER_FILTER options embedded.

My question is: what happens when a single mapping with options is too
large to fit in a PCP response? This can happen for example when many
FILTER options were added in separate PCP requests.

Do we strip off some options? Do we fragment somehow? All solutions I
can think of are either too complex or don't fully solve this problem.

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: <[email-masked]>
Date: Thu, 21 Apr 2011 13:46:50 +0200

Hi Simon,

This is indeed a case which may occur when a large number of FILTERs are defined. This may even be exacerbated if we associate "Description Option" (text to describe a mapping) with each FILTER for instance.

Note the GET mechanism allows to walk through mappings having the same internal IP@/port, external IP@/port and retrieve the list of FILTERs (i.e., distinct remote IP addresses/ports) if the same ordering is used to answer two GET/NEXT requests; see the following example:

                       |           PCP GET Response        |
                       |               MORE                |
                       |           protocol= TCP           |
                       | internal-ip-address= 198.51.100.2 |
                       |        internal-port= 12354       |
                       |   external-ip-address= 192.0.2.1  |
                       |        external-port= 32654       |
                       |       remaining-lifetime= 3600    |
                       |             DESCRIPTION           |
                       |      "My mapping for Server_A"    |
                       |               FILTER              |
                       |     remote-ip-address= 1.2.3.4    |
                       |          remote-port= 8965        |
                       |               FILTER              |
                       |     remote-ip-address= 45.63.25.2 |
                       |          remote-port= 1454        |
                       |               FILTER              |
                       |     remote-ip-address= 45.6.5.5   |
                       |          remote-port= 8965        |
                       |               ...                 |
                       |               FILTER              |
                       |          remote-port= 25659       |
                       |       remaining-lifetime= 6000    |
                       |<----------------------------------|
                       |           PCP GET Request         |
                       |               MORE                |
                       |           protocol= TCP           |
                       | internal-ip-address= 198.51.100.2 |
                       |        internal-port= 12354       |
                       |   external-ip-address= 192.0.2.1  |
                       |        external-port= 32654       |
                       |       remaining-lifetime= 3600    |
                       |             DESCRIPTION           |
                       |      "My mapping for Server_A"    |
                       |               FILTER              |
                       |     remote-ip-address= 1.2.3.4    |
                       |          remote-port= 8965        |
                       |               FILTER              |
                       |     remote-ip-address= 45.63.25.2 |
                       |          remote-port= 1454        |
                       |               FILTER              |
                       |     remote-ip-address= 45.6.5.5   |
                       |          remote-port= 8965        |
                       |               ...                 |
                       |               FILTER              |
                       |          remote-port= 25659       |
                       |       remaining-lifetime= 6000    |
                       |---------------------------------->|
                       |           PCP GET Response        |
                       |               MORE                |
                       |           protocol= TCP           |
                       | internal-ip-address= 198.51.100.2 |
                       |        internal-port= 12354       |
                       |   external-ip-address= 192.0.2.1  |
                       |        external-port= 32654       |
                       |       remaining-lifetime= 3600    |
                       |             DESCRIPTION           |
                       |      "My mapping for Server_A"    |
                       |               FILTER              |
                       |     remote-ip-address= 11.22.25.1 |
                       |          remote-port= 8965        |
                       |               FILTER              |
                       |          remote-port= 25659       |
                       |       remaining-lifetime= 6000    |
                       |               MORE                |
                       |           protocol= TCP           |
                       | internal-ip-address= 198.51.100.2 |
                       |        internal-port= 12354       |
                       |   external-ip-address= 192.0.2.1  |
                       |        external-port= 32654       |
                       |       remaining-lifetime= 3600    |
                       |               END                 |
                       |           protocol= TCP           |
                       | internal-ip-address= 198.51.100.2 |
                       |        internal-port= 8596        |
                       |   external-ip-address= 192.0.2.1  |
                       |        external-port= 25659       |
                       |       remaining-lifetime= 6000    |
                       |<----------------------------------|

Even if I think this is marginal for the NAT case, it would be useful to have some guidelines in the GET specification when it occurs such as: 

* Options which apply to all mappings having the same internal IP @/port are returned first
* "specific" options (eg. FILTER) are then returned in subsequent GET/NEXT messages.

Any suggestion is welcome.
Cheers,
Med 

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Simon Perreault
Envoyé : mercredi 20 avril 2011 21:16
À : [email-masked]
Cc : [email-masked]
Objet : [pcp] When a single mapping is too large to fit in a PCP GET/NEXT response

Hi,

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
[email-masked]
https://www.ietf.org/mailman/listinfo/pcp

---

From: Simon Perreault <[email-masked]>
Date: Thu, 21 Apr 2011 08:47:45 -0400

> Note the GET mechanism allows to walk through mappings having the same internal IP@/port, external IP@/port and retrieve the list of FILTERs (i.e., distinct remote IP addresses/ports) if the same o…

Do you mean "allows as currently specified" or "could allow in a future
draft revision"? I will assume the latter.

>                        |       remaining-lifetime= 6000    |

Yeah, that's one of the "too complex" solutions I was thinking of. It
also adds a new ordering constraint on all mapping options. I'm not
saying it would not work, but it doesn't look appealing at this point.

> * "specific" options (eg. FILTER) are then returned in subsequent GET/NEXT messages.

If I understand this correctly, this would mitigate the problem but not
eliminate it completely. It would just happen less often. So we would
need something more.

> Any suggestion is welcome.

TCP? I'm not joking. To me, transferring state in bulk seems very
appropriate for TCP.

Simon

---

From: Simon Perreault <[email-masked]>
Date: Thu, 21 Apr 2011 08:51:16 -0400

On 2011-04-21 08:42, Francis Dupont wrote:
> IMHO the obvious solution is to convert FILTER to OpCodes,
> something we should do anyway if we'd like to provide a real support
> to firewalls...

Yeah, that would work.

> PS: I don't see messages from the PCP ML itself ([email-masked])???

I think Mailman doesn't send you a copy when it sees your address in the
To: or Cc: headers. It's configurable per-user from the web interface...

Simon

---

From: <[email-masked]>
Date: Thu, 21 Apr 2011 16:20:54 +0200

Re-,

Please see inline.

Cheers,
Med 

-----Message d'origine-----
De : Simon Perreault [mailto:[email-masked]] 
Envoyé : jeudi 21 avril 2011 14:48
À : BOUCADAIR Mohamed OLNC/NAD/TIP
Cc : [email-masked]; [email-masked]
Objet : Re: [pcp] When a single mapping is too large to fit in a PCP GET/NEXT response

Med: I meant the currently defined mechanism could allow for it if the Options are part of the Locator. 

Med: IMO, this is would be sufficient for the CGN case.

Med: Why not but as you know the base PCP supports only UDP.

---

From: <[email-masked]>
Date: Thu, 21 Apr 2011 16:22:02 +0200

Hi Francis,

Yes, you are right. 

If we extend the Locator to include the Mapping Options this would be possible then.

Cheers,
Med

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] 
Envoyé : jeudi 21 avril 2011 14:43
À : BOUCADAIR Mohamed OLNC/NAD/TIP
Cc : Simon Perreault; [email-masked]; [email-masked]
Objet : Re: [pcp] When a single mapping is too large to fit in a PCP GET/NEXT response 

Mohammed, your example doesn't work because the option is not part of
the locator. IMHO the obvious solution is to convert FILTER to OpCodes,
something we should do anyway if we'd like to provide a real support
to firewalls...

   * "specific" options (eg. FILTER) are then returned in subsequent GET/NEXT
   messages.
   
=> subsequent == current location is in the request.

Regards

[email-masked]