Subject: [pcp] Hoping to eliminate MISORDERED_OPTIONS

From: Simon Perreault <[email-masked]>
Date: Sun, 27 Mar 2011 11:11:59 +0200

Hi,

Since it's currently in vogue to eliminate error codes, I thought I'd pitch in.

I stole this idea from the presentation on CoAP at the Internet of Things
tutorial yesterday.

The idea is to change the PCP protocol to make it impossible to express
unordered options. The way this is done is that instead of sending the option
code on the wire, we send the difference between the previous option code and
the next.

Example:

Instead of sending:

2 FILTER
2 FILTER
4 THIRD_PARTY

You'd send:

2 FILTER
0 FILTER
2 THIRD_PARTY

This is better because:
- Less server code: no need to check option order and send an error response.
- Less client code: no need to handle this error response.
- Interoperability issues are avoided.

Simon
-- 
NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca
STUN/TURN server        --> http://numb.viagenie.ca
vCard 4.0               --> http://www.vcarddav.org

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 28 Mar 2011 15:00:21 +0200

So, instead of Type/Length/Value, you are suggesting we do
Difference-of-Type/Length/Value.  

I would rather we just eliminate the requirement to order options at all.
Requiring ordering brings little benefit but creates a risks and harms
interoperability.  In the Postel spirit, (being liberal in what we accept),
I doubt servers will really refuse mis-ordered options and as we have
discussed on this mailing list clients cannot ignore responses with
mis-ordered options.  Chatting with Stuart this morning, he had a great
example of the risk created by ordering, which I expect he will explain to
the group shortly.

-d

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Simon Perreault
> Sent: Sunday, March 27, 2011 11:12 AM
> To: [email-masked]
> Subject: [pcp] Hoping to eliminate MISORDERED_OPTIONS
> 
> Hi,
> 
> _______________________________________________
> pcp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pcp

---

From: Dave Thaler <[email-masked]>
Date: Mon, 28 Mar 2011 13:20:35 +0000

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Dan
> Wing
> Sent: Monday, March 28, 2011 3:00 PM
> To: 'Simon Perreault'; [email-masked]
> Subject: Re: [pcp] Hoping to eliminate MISORDERED_OPTIONS
> 
> So, instead of Type/Length/Value, you are suggesting we do Difference-of-
> Type/Length/Value.
> 

That sounds like a good idea to me.

-Dave

> interoperability.  In the Postel spirit, (being liberal in what we accept), I
> doubt servers will really refuse mis-ordered options and as we have
> discussed on this mailing list clients cannot ignore responses with mis-
> ordered options.  Chatting with Stuart this morning, he had a great example
> of the risk created by ordering, which I expect he will explain to the group
> shortly.
> 
> -d
> 
> > I stole this idea from the presentation on CoAP at the Internet of
> > Things tutorial yesterday.
> >
> > The idea is to change the PCP protocol to make it impossible to
> > express unordered options. The way this is done is that instead of
> > sending the option code on the wire, we send the difference between
> > the previous option code and the next.
> >
> > Example:
> >
> > Instead of sending:
> >
> > 2 FILTER
> > 2 FILTER
> > 4 THIRD_PARTY
> >
> > You'd send:
> >
> > 2 FILTER
> > 0 FILTER
> > 2 THIRD_PARTY
> >
> > This is better because:

---

From: Simon Perreault <[email-masked]>
Date: Mon, 28 Mar 2011 15:25:33 +0200

> I would rather we just eliminate the requirement to order options at all.

Me too! That would be my first choice. My proposal would not apply if we allow
options in any order.

> example of the risk created by ordering, which I expect he will explain to

I also am very worried about the interoperability risks that requiring options
to be ordered would imply. My proposal eliminates that risk.

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: Francis Dupont <[email-masked]>
Date: Mon, 28 Mar 2011 15:39:31 +0200

In your previous mail you wrote:

=> 1000000+

[email-masked]

---

From: <[email-masked]>
Date: Tue, 29 Mar 2011 19:11:31 +0800

|So, instead of Type/Length/Value, you are suggesting we do 
|Difference-of-Type/Length/Value.  
|
|I would rather we just eliminate the requirement to order 
|options at all.
|Requiring ordering brings little benefit but creates a risks 
|and harms interoperability.  In the Postel spirit, (being 
|liberal in what we accept), I doubt servers will really refuse 
|mis-ordered options and as we have discussed on this mailing 
|list clients cannot ignore responses with mis-ordered options. 
| Chatting with Stuart this morning, he had a great example of 
|the risk created by ordering, which I expect he will explain 
|to the group shortly.

I don't object for eliminating the option order. But, again,
the THIRD_PARTY option makes AFTR implementation complicated,
because the AFTR needs to parse (often done by hardware)
internal IP address for ACL purpose before parsing the whole PCP header.

BR,
Xiaohong

|
|-d
|
|
|> -----Original Message-----
|> From: [email-masked] [mailto:[email-masked]] On 
|Behalf Of 
|> Simon Perreault
|> Sent: Sunday, March 27, 2011 11:12 AM
|> To: [email-masked]
|> Subject: [pcp] Hoping to eliminate MISORDERED_OPTIONS
|> 
|> Hi,
|> 
|> Since it's currently in vogue to eliminate error codes, I 
|thought I'd 
|> pitch in.
|> 
|> I stole this idea from the presentation on CoAP at the Internet of 
|> Things tutorial yesterday.
|> 
|> The idea is to change the PCP protocol to make it impossible to 
|> express unordered options. The way this is done is that instead of 
|> sending the option code on the wire, we send the difference between 
|> the previous option code and the next.
|> 
|> Example:
|> 
|> Instead of sending:
|> 
|> 2 FILTER
|> 2 FILTER
|> 4 THIRD_PARTY
|> 
|> You'd send:
|> 
|> 2 FILTER
|> 0 FILTER
|> 2 THIRD_PARTY
|> 
|> This is better because:
|> - Less server code: no need to check option order and send an error 
|> response.
|> - Less client code: no need to handle this error response.
|> - Interoperability issues are avoided.
|> 
|> Simon
|> --
|> NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca
|> STUN/TURN server        --> http://numb.viagenie.ca
|> vCard 4.0               --> http://www.vcarddav.org
|> _______________________________________________
|> pcp mailing list
|> [email-masked]
|> https://www.ietf.org/mailman/listinfo/pcp
|
|
|

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 29 Mar 2011 13:22:42 +0200

> From: [email-masked] [mailto:xiaohong.deng@orange-
> ftgroup.com]
> Sent: Tuesday, March 29, 2011 1:12 PM
> To: [email-masked]; [email-masked]; [email-masked]
> Subject: RE: [pcp] Hoping to eliminate MISORDERED_OPTIONS
> 
> 

AFTR is the DS-Lite's CGN+tunneling element.  "For ACL purpose" 
implies that some IPv4 address(es) would be invalid in the 
THIRD_PARTY option.  I have understood that DS-Lite allows the 
subscriber to use any IPv4 addresses the subscriber desires.  
If my understanding is correct, any IPv4 address in the 
THIRD_PARTY option is valid.

-d

---

From: Francis Dupont <[email-masked]>
Date: Tue, 29 Mar 2011 14:24:46 +0200

=> no, the internal IPv4 address is limited to "private addresses"
(i.e., RFC 1918 + the 192.0.0.0/29 prefix by default).
This requirement is a kind of higher level anti-spoofing/ingress
filtering one, in fact it follows the same rationale.

=> it is not but this doesn't mean the PCP server must implement
the ACL: IMHO it is better to perform all ACL checks (all because
in the plain mode the source IPv6 address must be validated too)
in one place, i.e., by the AFTR itself (I don't mean such mappings
should be accepted because they will be impossible to use, I mean
the checking code and in particular the configuration must not be
duplicated).

Regards

PS: in draft-ietf-softwire-dual-stack-lite-07.txt this is in section 11
(security considerations) at the middle of page 13:

   When decapsulating packets, the AFTR MUST only forward packets
   sourced by RFC 1918 addresses, IANA reserved address range, or any
   other out-of-band pre-authorized addresses.  The AFTR MUST drop all
   others packets.  This prevents rogue devices from launching denial of
   service attacks using unauthorized public IPv4 addresses in the IPv4
   source header field or unauthorized transport port range in the IPv4
   transport header field.  For example, rogue devices could bombard a
   public web server by launching a TCP SYN ACK attack [RFC4987].  The
   victim will receive TCP SYN from random IPv4 source addresses at a
   rapid rate and deny TCP services to legitimate users.

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 29 Mar 2011 14:44:46 +0200

> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, March 29, 2011 2:25 PM
> To: Dan Wing
> Cc: [email-masked]; [email-masked];
> [email-masked]

Let's pretend, for the sake of argument, that someone does a MAP
with the THIRD_PARTY option containing the IPv4 address 198.41.0.4,
which is a.root-servers.net.

What would break?

-d

---

From: Francis Dupont <[email-masked]>
Date: Tue, 29 Mar 2011 15:33:32 +0200

=> two quick comments:
 - this is a softwire topic so should be discussed in the softwire
  mailing-list
 - I noted you kindly use a.root-servers.net and not f.root-servers.net

   What would break?
   
=> 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.
   
Regards

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 29 Mar 2011 15:43:46 +0200

> Sent: Tuesday, March 29, 2011 3:34 PM
> To: Dan Wing

I don't see the harm.  Please walk me through the life of the
malicious activity after the PCP MAP request containing THIRD_PARTY.

-d

---

From: Francis Dupont <[email-masked]>
Date: Tue, 29 Mar 2011 16:09:45 +0200

=> oops, I believe I didn't understand your question: if the question
is what is the harm to accept a MAP request which leads to an
unusable mapping IMHO the problems are:
 - it is not a good idea to not raise an error as soon as the mapping
  is known to be unusable
 - the filtering on the source IPv4 address is done in the from customer
  to Internet way so you can't assume the DoS traffic from the Internet
  to the fake/victim address won't be routed to the victim.

This proves there are at least two ways to extend the DS-Lite
security consideration point to the PCP context:
 - ask the (same) ACL to be applied to the internal address of MAP request
  (I am in favor of this as it makes sense, is easy to implement and
   can be put (stay!) inside PCP specs)
 - ask an AFTR to not forward packets from the Internet-facing side to
  the same side (generated ICMP errors should be the only exception).
  As an AFTR is essentially an asymmetrical device it should not be
  a real problem but this implies to modify the DS-Lite document and
  there is a better solution.

Does this answer to your concern?
   
Thanks

PS: we really should extend this discussion to softwire, in particular
if you disagree. And of course change the subject!