Subject: Re: [pcp] Hoping to eliminate MISORDERED_OPTIONS

From: <[email-masked]>
Date: Sat, 2 Apr 2011 11:34:53 +0800

|> => anything which can cause a lot of traffic (free tickets for the 
|> social this night :-) and overload lines... the problem is 
|an AFTR can 
|> be used as a redirect device, of course here it hides the original 
|> destination, not the original source which is more 
|interesting for the 
|> bad guy.
|
|I don't see the harm.  Please walk me through the life of the 
|malicious activity after the PCP MAP request containing THIRD_PARTY.

If internal IP address presents in the common header, AFTR 
could process packets as soon as PCP common header be parsed
(by hardware); otherwise AFTR needs to parse all the (not-ordered)
options to retrieve internal IP, which is a hurdle to hardware 
parsing. As a result, if the AFTR has to implement options parsing by 
software, it is likely to make PCP server a processing bottleneck.

BR,
Xiaohong
opensource A+P: http://opensourceaplusp.weebly.com/

|
|-d
|
|
|> Regards
|> 
|> [email-masked]
|
|

---

From: Francis Dupont <[email-masked]>
Date: Mon, 04 Apr 2011 16:21:13 +0200

In your previous mail you wrote:

   As a result, if the AFTR has to implement options parsing by
   software, it is likely to make PCP server a processing bottleneck.
   
=> IMHO it doesn't make sense to process PCP by hardware (PCP is
an extensible protocol so it will never work).

Regards

[email-masked]

PS: this argument applies to the PCP server co-located with a CGN.