Subject: Re: [pcp] #74 (third-party-id-option): Mohamed Boucadair's comments on draft-ietf-pcp-third-party-id-option-00

From: Rolf Winter <[email-masked]>
Date: Thu, 8 Jan 2015 15:55:29 +0000

Hi,

regarding the 128 octet maximum. In general, I am not a fan of magic constants. I would rather prefer another solution. Instead of fixing the maximum size, the draft should suggest a configuration option for the server to set a maximum acceptable ID size and an error to return if a request exceeds that size. The other PCP RFCs have done something similar, e.g. RFC 6887 section 11 it says:

PCP servers SHOULD provide a configuration option to allow
administrators to disable MAP support if they wish.

This way, we can protect against state exhaustion and remain flexible for larger IDs in the future. Would that work?

Best,

Rolf

NEC Europe Ltd | Registered Office: Athene, Odyssey Business Park, West End  Road, London, HA4 6QE, GB | Registered in England 2832014

> -----Original Message-----
> From: pcp [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: Dienstag, 16. Dezember 2014 07:34
> To: Andreas Ripke; [email-masked]
> Subject: Re: [pcp] #74 (third-party-id-option): Mohamed Boucadair's
> comments on draft-ietf-pcp-third-party-id-option-00
> 
> Hi Andreas,
> 
> Please see inline.
> 
> Cheers,
> Med
> 
> -----Message d'origine-----
> De : pcp [mailto:[email-masked]] De la part de Andreas Ripke
> Envoyé : lundi 15 décembre 2014 17:26 À : [email-masked] Objet : Re:
> [pcp] #74 (third-party-id-option): Mohamed Boucadair's comments on
> draft-ietf-pcp-third-party-id-option-00
> 
> Hi,
> 
> Med's comments contain two technical modifications.
> 
> 1. A recommended fixed maximum option length of 128 octets.
> 
> Why should we (unnecessarily?) set an explicit limit to this option?
> The fixed option length (16 octets) was changed to a variable length
> with the current draft version.
> The maximum PCP packet size is 1100 octets and the client must ensure
> not to cause an overrun according to RFC6887.
> But then, in RFC7220 the maximum variable length for the description
> option is limited to 1016 octets.
> Is there any special reason to have an explicit maximum option length
> defined?
> 
> [Med] Fixing a maximum is required to help dimensioning the server and
> to avoid exhausting server's resources. Most of the identifiers I'm
> aware of don't exceed 128 octets. Hence my recommendation to use that
> maximum.
> 
> 
> 2. The newly specified THIRD_PARTY_ID option can be used alone without
> the THIRD_PARTY option.
> 
> The THIRD_PARTY_ID option is defined as an extension to the THIRD_PARTY
> option in case the THIRD_PARTY address is not sufficient.
> Using the THIRD_PARTY_ID alone  seems to be a very special use case.
> Is there a practical application to it?
> 
> [Med] A host directly connected to a network or a CPE embedding a PCP
> client can use this option to carry the identifier. The internal IP
> address is carried in the opcode header; no need for the THIRD_PARTY in
> that case. Injecting both a THIRD_PARTY option and this one is
> deployment-specific.
> 
> Andreas
> 
> 
> > -----Original Message-----
> > From: pcp issue tracker [mailto:[email-masked]]
> > Sent: Thursday, December 11, 2014 10:23 PM
> > To: [email-masked];
> > [email-masked]
> > Cc: [email-masked]
> > Subject: [pcp] #74 (third-party-id-option): Mohamed Boucadair's
> > comments on
> > draft-ietf-pcp-third-party-id-option-00
> >
> > #74: Mohamed Boucadair's comments on
> > draft-ietf-pcp-third-party-id-option-
> > 00
> >
> >  Comments inline in PDF copy currently at
> >  http://research.microsoft.com/~dthaler/draft-ietf-pcp-third-party-
> id-
> >  option-00-Med.pdf
> >
> > --
> > -------------------------------------+-------------------------------
> -
> > -------------------------------------+-----
> >  Reporter:                           |      Owner:  draft-ietf-pcp-
> third-
> >   [email-masked]       |  party-id-
> [email-masked]
> >      Type:  defect                   |     Status:  new
> >  Priority:  major                    |  Milestone:  milestone1
> > Component:  third-party-id-option    |    Version:  1.0
> >  Severity:  In WG Last Call          |   Keywords:
> > -------------------------------------+-------------------------------
> -
> > -------------------------------------+-----
> >
> > Ticket URL: <https://tools.ietf.org/wg/pcp/trac/ticket/74>
> > pcp <http://tools.ietf.org/pcp/>
> 
> _______________________________________________
> pcp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pcp
> 
> _______________________________________________
> pcp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pcp

---

From: Dave Thaler <[email-masked]>
Date: Fri, 9 Jan 2015 01:36:52 +0000

Andreas Ripke writes: 
> The fixed option length (16 octets) was changed to a variable length with the
> current draft version.
> The maximum PCP packet size is 1100 octets and the client must ensure not to
> cause an overrun according to RFC6887.
> But then, in RFC7220 the maximum variable length for the description option is
> limited to 1016 octets.
> Is there any special reason to have an explicit maximum option length defined?
> 
> [Med] Fixing a maximum is required to help dimensioning the server and to
> avoid exhausting server's resources. Most of the identifiers I'm aware of don't
> exceed 128 octets. Hence my recommendation to use that maximum.

My personal opinion on the above is that the other limits Andreas mentions
are already sufficient and we don't need to specify a shorter limit than what
you naturally get.

-Dave

---

From: <[email-masked]>
Date: Fri, 9 Jan 2015 06:57:23 +0000

Hi Dave,

Hmm...but what will be the behavior of the server if it is not designed to support a length included in the PCP request? Should it truncate the fiele? Shouldn't this will lead to some side effects such as encountering errors to send a response or to validate the response at the client side because the content of the THIRD_PARTY_ID as included in the response does not match what has been included in the response, etc.?

For these reasons and also to help the design of PCP server, I do still think a max should be included as part of the specification. 128 octets seems reasonable.

Cheers,
Med

-----Message d'origine-----
De : Dave Thaler [mailto:[email-masked]] 
Envoyé : vendredi 9 janvier 2015 02:37
À : BOUCADAIR Mohamed IMT/OLN; Andreas Ripke; [email-masked]
Objet : RE: [pcp] #74 (third-party-id-option): Mohamed Boucadair's comments on draft-ietf-pcp-third-party-id-option-00

-Dave

---

From: Juergen Quittek <[email-masked]>
Date: Fri, 9 Jan 2015 07:41:06 +0000

Hi Med,

> Sent: Freitag, 9. Januar 2015 07:57
> To: Dave Thaler; Andreas Ripke; [email-masked]
> Subject: Re: [pcp] #74 (third-party-id-option): Mohamed Boucadair's comments
> on draft-ietf-pcp-third-party-id-option-00
> 
> Hi Dave,
> 
> Hmm...but what will be the behavior of the server if it is not designed to
> support a length included in the PCP request? Should it truncate the fiele?

Hi Med. This case is pretty clear. Of course it should not truncate an ID. 
If a server cannot support an ID sent to it, the ID is obviously unsuited 
and it should return an error message.

> Shouldn't this will lead to some side effects such as encountering errors to send
> a response or to validate the response at the client side because the content of
> the THIRD_PARTY_ID as included in the response does not match what has
> been included in the response, etc.?

If a server implements the THIRD_PARTY_ID, it needs to implement 
PCP variable length options and be able to return them in an error 
message.

> For these reasons and also to help the design of PCP server, I do still think a
> max should be included as part of the specification. 128 octets seems
> reasonable.

The PCP protocol supports variable length options. 
Are you talking about PCP servers that do not support them?

Best regards,
     Juergen

> Objet : RE: [pcp] #74 (third-party-id-option): Mohamed Boucadair's comments
> on draft-ietf-pcp-third-party-id-option-00
> 
> Andreas Ripke writes:

---

From: <[email-masked]>
Date: Fri, 9 Jan 2015 10:21:06 +0000

Re-,

Thank you for the clarification.

Please see inline.

Cheers,
Med

-----Message d'origine-----
De : Juergen Quittek [mailto:[email-masked]] 
Envoyé : vendredi 9 janvier 2015 08:41
À : BOUCADAIR Mohamed IMT/OLN; Dave Thaler; Andreas Ripke; [email-masked]
Objet : RE: [pcp] #74 (third-party-id-option): Mohamed Boucadair's comments on draft-ietf-pcp-third-party-id-option-00

Hi Med,

[Med] Agree. I'm expecting some text to call this out. A new result code is to be defined IMHO: e.g., UNSUPP_OPTION_LENGTH or something similar.  

[Med] Agree about this. My point is I want to be sure no error is returned for a THIRD_PARTY_ID < 128 octets.   

[Med] No. It is more about the dimensioning of the PCP server + be sure that schemes that are likely to be deployed are supported by servers with no risk to encounter errors because of an implementation choice. Getting an error won't help the client to get the service. 

Best regards,
     Juergen

---

From: Juergen Quittek <[email-masked]>
Date: Fri, 9 Jan 2015 14:10:33 +0000

Hi Med,

I have a different view on the option length handling. The option is used to managed entries in mapping tables. I would assume that when you implement a server and its mapping tables you know which sizes of THIRD_PARTY_IDs your table can support. If the server receives a request with a not supported option length, it should return an error message. It does not matter if the option length is too long or too short.

Cheers,
    Juergen

> From: [email-masked]
> [mailto:[email-masked]]
> Sent: Freitag, 9. Januar 2015 11:21
> To: Juergen Quittek; Dave Thaler; Andreas Ripke; [email-masked]
> Subject: RE: [pcp] #74 (third-party-id-option): Mohamed Boucadair's comments
> comments
> [Med] Agree. I'm expecting some text to call this out. A new result code is to be
> defined IMHO: e.g., UNSUPP_OPTION_LENGTH or something similar.
> 
> [Med] No. It is more about the dimensioning of the PCP server + be sure that
> schemes that are likely to be deployed are supported by servers with no risk to
> encounter errors because of an implementation choice. Getting an error won't
> help the client to get the service.
> 
> Best regards,
>      Juergen
> 
> > Cheers,
> > Med
> >
> option
> > is

---

From: Andreas Ripke <[email-masked]>
Date: Fri, 16 Jan 2015 11:00:06 +0000

>From the proposed two technical modifications
the recommended fixed maximum option length of 128 octets
was not included into the new draft-ietf-pcp-third-party-id-option-01
as argued below. The RFC 6887 limits already the
overall option space and the future use of this identifier
shouldn't be unnecessarily limited by currently used identifiers.

Using the THIRD_PARTY_ID option without the THIRD_PARTY option
was adopted as deployment cases are already known.

Some of the Med's other editing comments were included
as appropriate for the technical change.

Andreas

> From: Juergen Quittek
> Sent: Friday, January 09, 2015 3:11 PM
> To: [email-masked]; Dave Thaler; Andreas Ripke;
> [email-masked]
> I have a different view on the option length handling. The option is used to
> managed entries in mapping tables. I would assume that when you implement
> a server and its mapping tables you know which sizes of THIRD_PARTY_IDs your
> table can support. If the server receives a request with a not supported option
> length, it should return an error message. It does not matter if the option
> length is too long or too short.
> 
> Cheers,
>     Juergen
> 
> > Subject: RE: [pcp] #74 (third-party-id-option): Mohamed Boucadair's
> > De : Juergen Quittek [mailto:[email-masked]] Envoyé : vendredi 9
> > janvier 2015 08:41 À : BOUCADAIR Mohamed IMT/OLN; Dave Thaler;
> Andreas
> > Ripke; [email-masked] Objet : RE: [pcp] #74 (third-party-id-option):
> > Mohamed Boucadair's comments on
> > > Hmm...but what will be the behavior of the server if it is not
> > > designed to support a length included in the PCP request? Should it truncate
> the fiele?
> >
> > If a server cannot support an ID sent to it, the ID is obviously
> > unsuited and it should return an error message.
> >
> > [Med] Agree. I'm expecting some text to call this out. A new result
> > code is to be defined IMHO: e.g., UNSUPP_OPTION_LENGTH or something
> similar.
> >
> > > Shouldn't this will lead to some side effects such as encountering
> > > errors to
> > send
> > > a response or to validate the response at the client side because
> > > the content
> > of
> > > the THIRD_PARTY_ID as included in the response does not match what
> > > has been included in the response, etc.?
> >
> > If a server implements the THIRD_PARTY_ID, it needs to implement PCP
> > variable length options and be able to return them in an error
> > message.
> >
> > [Med] Agree about this. My point is I want to be sure no error is
> > returned for a THIRD_PARTY_ID < 128 octets.
> >
> > > For these reasons and also to help the design of PCP server, I do
> > > still think a max should be included as part of the specification.
> > > 128 octets seems reasonable.
> >
> > [Med] No. It is more about the dimensioning of the PCP server + be
> > sure that schemes that are likely to be deployed are supported by
> > servers with no risk to encounter errors because of an implementation
> > choice. Getting an error won't help the client to get the service.
> >
> > Best regards,
> >      Juergen
> >
> > > Cheers,
> > > Med
> > >
> > > De : Dave Thaler [mailto:[email-masked]] Envoyé : vendredi 9
> > > janvier 2015 02:37 À : BOUCADAIR Mohamed IMT/OLN; Andreas Ripke;
> > > [email-masked] Objet : RE: [pcp] #74 (third-party-id-option): Mohamed
> > > Boucadair's
> > comments
> > > > The fixed option length (16 octets) was changed to a variable
> > > > length with
> > the
> > > > current draft version.
> > > > The maximum PCP packet size is 1100 octets and the client must
> > > > ensure not
> > > to
> > > > [Med] Fixing a maximum is required to help dimensioning the server
> > > > and to avoid exhausting server's resources. Most of the
> > > > identifiers I'm aware of
> > > don't
> > > My personal opinion on the above is that the other limits Andreas
> > > mentions are already sufficient and we don't need to specify a
> > > shorter limit than what you naturally get.
> > >
> > > -Dave
> > >

---

From: <[email-masked]>
Date: Mon, 19 Jan 2015 10:00:11 +0000

Dear Andreas,

The explanation provided by Juergen for the point about including a recommended supported max length makes sense. 
  
This version is much better. Below some comments about this version:

* You may consider adding some words about the lifetime of the errors (short/long) + a description text for each new result code.
* Section 7: 
 (1) Cite the appropriate sections from RFC6887. 
 (2) I would update this sentence " The
   THIRD_PARTY_ID option might carry privacy information like location
   or profile information. " to for example: "The
   THIRD_PARTY_ID option might carry privacy information like location
   or profile information. Means to defend against such practice should be enabled."
  
Thank you.

Cheers,
Med

-----Message d'origine-----
De : pcp [mailto:[email-masked]] De la part de Andreas Ripke
Envoyé : vendredi 16 janvier 2015 12:00
À : [email-masked]
Objet : Re: [pcp] #74 (third-party-id-option): Mohamed Boucadair's comments on draft-ietf-pcp-third-party-id-option-00

Andreas

---

From: Rolf Winter <[email-masked]>
Date: Mon, 26 Jan 2015 09:27:59 +0000

Hi,

see inline.

> Sent: Montag, 19. Januar 2015 11:00
> To: Andreas Ripke
> Cc: [email-masked]
> The explanation provided by Juergen for the point about including a
> recommended supported max length makes sense.
> 
> * You may consider adding some words about the lifetime of the errors
> (short/long) + a description text for each new result code.
> * Section 7:

I don't think this additional sentence makes sense. I think what you mean is something along these lines: "Means to protect unauthorized access to this information should be put in place."

Is that correct?

Best,

Rolf

> Envoyé : vendredi 16 janvier 2015 12:00 À : [email-masked] Objet : Re:
> the recommended fixed maximum option length of 128 octets was not
> included into the new draft-ietf-pcp-third-party-id-option-01
> as argued below. The RFC 6887 limits already the overall option space
> and the future use of this identifier shouldn't be unnecessarily
> limited by currently used identifiers.
> 
> Using the THIRD_PARTY_ID option without the THIRD_PARTY option was
> adopted as deployment cases are already known.
> 
> Some of the Med's other editing comments were included as appropriate
> for the technical change.
> 
> Andreas
> 
> > I have a different view on the option length handling. The option is
> > used to managed entries in mapping tables. I would assume that when
> > you implement a server and its mapping tables you know which sizes of
> > THIRD_PARTY_IDs your table can support. If the server receives a
> > request with a not supported option length, it should return an error
> > message. It does not matter if the option length is too long or too
> short.
> >
> > Cheers,
> >     Juergen
> >
> PCP
> > > servers with no risk to encounter errors because of an
> > > implementation choice. Getting an error won't help the client to
> get the service.
> > >
> > > Best regards,
> > >      Juergen
> > >
> > > > Cheers,
> > > > Med
> > > >
> > > > De : Dave Thaler [mailto:[email-masked]] Envoyé : vendredi
> > > > 9 janvier 2015 02:37 À : BOUCADAIR Mohamed IMT/OLN; Andreas
> Ripke;
> > > > [email-masked] Objet : RE: [pcp] #74 (third-party-id-option):
> > > > Mohamed Boucadair's
> > > comments
> > > > > [Med] Fixing a maximum is required to help dimensioning the
> > > > > server and to avoid exhausting server's resources. Most of the
> > > > > identifiers I'm aware of
> > > > don't