Subject: [Softwires] MAP based attribution and spoofing

From: "cb.list6" <[email-masked]>
Date: Thu, 25 Apr 2013 08:07:08 -0700

Hi,

Tom Taylor just sent a mail to behave on logging that piqued my interest.

The MAP based solutions set is stateless.

And therefore it has an elegant solution for those interested in
attribution, specifically in the context of law enforcement.

Can someone explain where I can find a pointer on how the stateless mapping
holds up to spoofing from the MAP domain? Could a malicious user send bad
packets where this attribution model attributes the bad packets to a 3rd
party.

If Alice and Bob are communicating, could Dec send a packets through the BR
appearing to be from Alice where destination is Bob.

Stateless is great. But there is no chance that the MAP BR is not the new
open DNS resolver, right ?

If this is already covered, a simple pointer is all I need.

Will this type of attribution be sufficient for courts ? Or is it
circumstantial ?

CB.

---

From: Shishio Tsuchiya <[email-masked]>
Date: Fri, 26 Apr 2013 00:35:49 +0900

CB
MAP validate onsistency of the source IPv6 address and source port number for the packet using BMR.
It dicribes section 8.1.
http://tools.ietf.org/html/draft-ietf-softwire-map-05#section-8.1

I can't understand why you are saying about open DNS resolver in this question.
Basically MAP domain includes CE are managed by service provider.
MAP-CE should configure as it does not response for query from WAN.

Regards,
-Shishio

(2013/04/26 0:07), cb.list6 wrote:
> And therefore it has an elegant solution for those interested in attribution, specifically in the context of law enforcement.
> 
> Can someone explain where I can find a pointer on how the stateless mapping holds up to spoofing from the MAP domain? Could a malicious user send bad packets where this attribution model attributes the bad packets to a 3rd party.
> 
> If Alice and Bob are communicating, could Dec send a packets through the BR appearing to be from Alice where destination is Bob.
> 
> Stateless is great. But there is no chance that the MAP BR is not the new open DNS resolver, right ?
> 
> Will this type of attribution be sufficient for courts ? Or is it circumstantial ?
> 
> CB.
> 
> 
> 
> _______________________________________________
> Softwires mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/softwires
>

---

From: "cb.list6" <[email-masked]>
Date: Thu, 25 Apr 2013 10:10:38 -0700

> MAP-CE should configure as it does not response for query from WAN.

 i am mostly thinking of a rogue MAP-CE spoofing may cause lots of
problems on the BR (port dos, already noted in the draft) and
undermining the attribution features of MAP.  If a criminal in a court
can say spoofing is possible and anyone could have sent those illegal
packets, then they can deny the attribution features of MAP.  It seems
like if rogue MAP-CE spoofing is not explicitly denied at the
attachment PE router with a "MUST use RFC 2827" in the
draft-ietf-softwire-map, then there is a problem with the spec that
should be resolved.  So, the MAP team may want to add that.

---

From: Satoru Matsushima <[email-masked]>
Date: Fri, 26 Apr 2013 03:15:12 +0900

On 2013/04/26, at 2:10, "cb.list6" <[email-masked]> wrote:

> undermining the attribution features of MAP.  

While it looks as same as 6rd, DS-Lite and 464XLAT, what kind of things are MAP specific.

> If a criminal in a court
> packets, then they can deny the attribution features of MAP.  

While it looks as same as 6rd, DS-Lte and 464XLAT, what kind of feature is MAP specific.

> It seems

What you suggesting looks like making boiler-plate RFC that says "all kind of IPv6 transition solutions MUST be deployed in network which is under RFC2827 operation, that all." Or, applying that boiler-plate amendment to all published RFCs.

cheers,
--satoru

---

From: "cb.list6" <[email-masked]>
Date: Thu, 25 Apr 2013 12:28:34 -0700

> While it looks as same as 6rd, DS-Lite and 464XLAT, what kind of things are MAP specific.

That's a fair point.

But, it is MAP that is in last call. My suggestion is about making MAP
a better standard by adding a MUST implemented spoofing protection at
the PE.

Cameron

---

From: Ole Troan <[email-masked]>
Date: Thu, 25 Apr 2013 22:04:00 +0200

Cameron,

> a better standard by adding a MUST implemented spoofing protection at

8.1.  Receiving rules

   The CE SHOULD check that MAP received packets' transport-layer
   destination port number is in the range configured by MAP for the CE
   and the CE SHOULD drop any non conforming packet and respond with an
   ICMPv6 "Address Unreachable" (Type 1, Code 3).

you are suggesting to make these MUSTs?
and perhaps adopts similar text to what's in RFC5969, section 9.2?

I wouldn't object to that. IPv4 should be as well protected against spoofing
as the underlaying IPv6 is.

cheers,
Ole

---

From: "cb.list6" <[email-masked]>
Date: Thu, 25 Apr 2013 13:30:30 -0700

> as the underlaying IPv6 is.

My concern is at the rogue MAP CE.  Thus, the spoof protection
filtering should be applied at the attachment PE so that the rogue MAP
CE attempts at spoofing can squashed at the provider edge.

Make sense?

CB

---

From: Shishio Tsuchiya <[email-masked]>
Date: Fri, 26 Apr 2013 12:02:53 +0900

Cameron

> CE attempts at spoofing can squashed at the provider edge.

The customer is permitted IPv6 access and internet,but not permitted use MAP CE in this case.
Correct?

I agree BCP38/RFC2827 should use edge of IPv4/IPv6 ISP,but it does not means on MAP-BR and MAP specific topic.
It should do IPv6 side interface.
So I think we don't need the description for map draft.

Regards,
-Shishio

---

From: Ole Troan <[email-masked]>
Date: Fri, 26 Apr 2013 09:22:19 +0200

Cameron,

> CE attempts at spoofing can squashed at the provider edge.

yes, that was what I meant too (albeit not what I wrote ;-)).
the receiving consistency check has to be done both on BR and CE.

cheers,
Ole

---

From: Shishio Tsuchiya <[email-masked]>
Date: Fri, 26 Apr 2013 17:08:12 +0900

BTW,I think we should describe this open resolver issue in CPE requirement.
http://www.apricot2013.net/__data/assets/pdf_file/0009/58878/tom-paseka_1361839564.pdf

like a "The CPE MUST not be open resolver from WAN side."

http://tools.ietf.org/html/draft-ietf-v6ops-6204bis
 and
RFC1812
http://tools.ietf.org/html/rfc1812

What do you think?

---

From: Simon Perreault <[email-masked]>
Date: Fri, 26 Apr 2013 11:03:11 +0200

> the receiving consistency check has to be done both on BR and CE.

That is still not answering Cameron's point IMHO.

- First, doing spoof prevention on the BR doesn't prevent spoofed 
packets from reaching other MAP CEs directly. Second, it allows packets 
to travel across the ISPs network: ideally you'd want to drop them at 
the edge (PE).

- Doing spoof prevention on the CE prevents nothing because it's a rogue 
CE you're trying to protect the network against.

As I understand it, Cameron is suggesting that the PE inspect inside 
IPv6 packets encapsulating IPv4 packets to apply the MAP spoof check on 
the IPv4 source address. This would prevent spoofed MAP packets (correct 
external IPv6 source  but spoofed internal IPv4 source) from reaching 
the BR or other MAP CEs.

Makes sense to me.

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: Ole Troan <[email-masked]>
Date: Fri, 26 Apr 2013 11:20:20 +0200

Simon,

> - First, doing spoof prevention on the BR doesn't prevent spoofed packets from reaching other MAP CEs directly. Second, it allows packets to travel across the ISPs network: ideally you'd want to drop them at the edge (PE).

every MAP node does the spoof protection. that prevents spoofed packets from reaching other the MAP CEs.
as a deployment consideration, the borders of the MAP domain should be protected to hinder tunnelled packets
escaping or entering.

> - Doing spoof prevention on the CE prevents nothing because it's a rogue CE you're trying to protect the network against.

doing it on the CE (as well as on the BR) prevents other CEs in the same domain accepting traffic from the rogue CE.

> As I understand it, Cameron is suggesting that the PE inspect inside IPv6 packets encapsulating IPv4 packets to apply the MAP spoof check on the IPv4 source address. This would prevent spoofed MAP packets (correct external IPv6 source  but spoofed internal IPv4 source) from reaching the BR or other MAP CEs.
> 
> Makes sense to me.

you are saying that every PE needs to know the MAP rules. isn't that making them into a MAP BR?
in any case, the MAP specification should not specify behaviour on non-MAP nodes.

cheers,
Ole

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Fri, 26 Apr 2013 14:50:48 +0000

Typically, an IP address pertains to a CPE. So, a common BCP is to employ
uRPF to detect/mitigate the source-address spoofing.

In A+P environment (such as that of MAP), an IPv4 address + port-range
pertain to a CPE. So, it is tempting to think that the port-range aware
uRPF is needed to avoid the source-address-port spoofing.

Thankfully, in MAP, both CE and BR employ the so called port-range aware
uRPF, as Ole well clarified. So, the possibility of any device causing any
grief to any other device (in the network - CE or outside the network -
via BR) just does NOT exist.

Of course, the source IPv6 address used by the MAP CE is still very much
subjected to the typical uRPF on any IP node in the network.

All-in-all, MAP nodes (e.g. CE) can't become " open DNS resolver" or
attribute the bad packets to a 3rd party.

I don't expect any changes in the MAP spec.

Cheers,
Rajiv

-----Original Message-----
From: Ole Troan <[email-masked]>
Date: Friday, April 26, 2013 5:20 AM
To: Simon Perreault <[email-masked]>
Cc: Softwires-wg list <[email-masked]>
Subject: Re: [Softwires] MAP based attribution and spoofing

>> - Doing spoof prevention on the CE prevents nothing because it's a
>>rogue CE you're trying to protect the network against.
>
>doing it on the CE (as well as on the BR) prevents other CEs in the same
>domain accepting traffic from the rogue CE.
>

---

From: Simon Perreault <[email-masked]>
Date: Fri, 26 Apr 2013 17:22:37 +0200

> via BR) just does NOT exist.

Right.

In this security model, spoofed packets are allowed to be injected in 
the MAP domain. They will travel all the way to their destination. When 
they reach it, the spoof check is performed, and at this point they are 
dropped.

In other words, in the MAP model the check is at the egress point, 
whereas in the BCP38 model the check is at the ingress point.

Egress checking could be well justified, but it needs to at least be 
specifically highlighted in the security considerations section.

Simon

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Fri, 26 Apr 2013 15:42:31 +0000

I agree, Simon. 

Cheers,
Rajiv

-----Original Message-----
From: Simon Perreault <[email-masked]>
Date: Friday, April 26, 2013 11:22 AM
To: Rajiv Asati <[email-masked]>
Cc: Ole Troan <[email-masked]>, Softwires-wg list
<[email-masked]>

---

From: "cb.list6" <[email-masked]>
Date: Fri, 26 Apr 2013 09:01:33 -0700

> I don't expect any changes in the MAP spec.

Ok, let me explain a possible threat and you tell me if existing
countermeasures are sufficient.

A rogue map ce starts sending malicious random SYN flood traffic to the
BR.  The rogue CPE is spoofing addresses from the MAP domain.  It cycles
through source addresses and port pairs.

My thought is urpf on the attachment pe would limit this issue

CB.

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Fri, 26 Apr 2013 17:03:03 +0000

Hi Cameron,

>BR.  The 

This is nothing different from the scenario of a rogue CE in non-MAP
environment sending unwanted traffic to an unknown destination. The first
hop router (and subsequent routers) forward the traffic, per the default
route, but the traffic gets dropped at the boundary router, which has the
full routing table (with specific routes). There is no spoofing in this
case, of course. 

> My thought is urpf on the attachment pe would limit this issue

I agree, but it is outside the MAP specification, IMO.

Cheers,
Rajiv

-----Original Message-----
From: Cameron Byrne <[email-masked]>
Date: Friday, April 26, 2013 12:01 PM
To: Rajiv Asati <[email-masked]>
Cc: Ole Troan <[email-masked]>, Simon Perreault
<[email-masked]>, Softwires-wg list <[email-masked]>
Subject: Re: [Softwires] MAP based attribution and spoofing

---

From: Ole Troan <[email-masked]>
Date: Fri, 26 Apr 2013 23:24:04 +0200

> I agree, but it is outside the MAP specification, IMO.

a) the BR operator knows who the rogue CE is based on the IPv6 source address.
   (assuming IPv6 BCP38, if not, you're in trouble)
b) the BR is stateless, it doesn't care about SYN packets, it can silently drop any packet
    violating the check  at high rate.

cheers,
Ole

---

From: Mark Townsley <[email-masked]>
Date: Tue, 30 Apr 2013 14:19:48 +0200

On Apr 26, 2013, at 5:22 PM, Simon Perreault wrote:

> In this security model, spoofed packets are allowed to be injected in the MAP domain.
> They will travel all the way to their destination. When they reach it, the spoof check is performed, and at this point they are dropped.
> 
> In other words, in the MAP model the check is at the egress point, whereas in the BCP38 model the check is at the ingress point.

MAP is checking the mapping between the IP overlay and underlay. No more, no less. It is not doing, and thus is not a replacement for, BCP38. BCP 38 should still be done, for IPv4 and IPv6, at appropriate locations, independently of MAP. 

> 
> Egress checking could be well justified, but it needs to at least be specifically highlighted in the security considerations section.

Just be sure to identify that which is general best practice for any IPv6 or IPv4 network edge, and that which is MAP-specific. We don't want feature creep into MAP that which is generally applicable to any single or dual-stack network.

- Mark