Subject: Re: [v6ops] Fwd: 82nd IETF DRAFT Agenda

From: Ray Hunter <[email-masked]>
Date: Wed, 26 Oct 2011 22:04:23 +0200

I raised concerns about draft-xli-v6ops-ivi-icmp-address-00.txt when it 
was originally discussed on this list last July.

The draft has not been updated since, so my concerns remain.

There now seems to be a number of people on the list who see its 
benefit, and are supporting the draft.

IMHO Due consideration should be made to weigh up the likely operational 
cost incurred because (many?) operators will have to change a lot of 
operational filters (to avoid the very likely abuse of this special 
range as a DDOS source) against the likely operational benefit for the 
(few?) operators who have applied this technology.

There are alternatives available for address ranges to use as a source 
address of translations within the AS without assigning a new global 
special purpose range (either RFC1918, or a privately assigned block of 
public IPv4 addresses from existing space, which can be shared between 
operators).

Admittedly the alternatives are not very attractive. But neither is the 
translation of ICMP messages into a packet that carries very little 
value or information when observed outside of its own AS, which is not 
traceable, and which could in fact become a danger thus triggering a 
need for mass packet filter updates.

I asked at the time: can anyone think of any other example of a 
"one-way" special purpose packet that is allowed to leave the link, 
never mind the AS?  RFC1918 addresses are not allowed to cross 
inter-enterprise links (for good reasons).

Regards,
RayH

> Subject:
> Re: [v6ops] Fwd: 82nd IETF DRAFT Agenda
> From:
> Warren Kumari <[email-masked]>
> Date:
> Wed, 26 Oct 2011 07:32:35 -0400
>
> To:
> Xing Li <[email-masked]>
> CC:
> "[email-masked] WG" <[email-masked]>, V6ops Chairs 
> <[email-masked]>
>
> Content-Transfer-Encoding:
> quoted-printable
> Precedence:
> list
> MIME-Version:
> 1.0 (Apple Message framework v1084)
> References:
> <[email-masked]> 
> <[email-masked]> 
> <[email-masked]>
> In-Reply-To:
> <[email-masked]>
> Message-ID:
> <[email-masked]>
> Content-Type:
> text/plain; charset=utf-8
> Message:
> 1
>
>
> On Oct 24, 2011, at 6:36 AM, Xing Li wrote:
>
>    
>> >  Hi, Fred and All,
>> >  
>> >  ? 2011/10/14 5:52, Fred Baker ??:
>>      
>>> >>  The initial version of the agenda has been posted. It places v6ops on Wednesday and Friday mornings, a total of 4.5 hours. I personally am satisfied with it, but if folks have issues I can pass them along.
>>> >>  
>>> >>  I'll note that the deadline for -00 drafts is 24 October, and the deadline for updated drafts is a week later. For discussion in the working group meetings, I'm looking for a draft posted after 25 July, with supporting email discussion on the list.
>>> >>  
>>> >>  I'm looking for (and in some cases have seen) commentary on each of:
>>> >>  
>>> >>  -rw-rw-r--  1 fred  fred  13796 Jul 25 23:59 draft-xli-v6ops-ivi-icmp-address-00.txt
>>>        
>> >  
>> >  I would like to request that the V6ops WG adopt draft-xli-v6ops-ivi-icmp-address-00.txt as a WG adoption.
>> >  
>> >  The draft describes the operational considerations of mapping ICMPv6 packets through an RFC6145 gateway where the IPv6 address is not directly translatable into an IPv4 address, and requests an IANA Special Purpose IPv4 address allocation (192.70.192.0/24) to allow this address mapping to take place using a protocol-specific designated address block in IPv4.
>> >  
>>      
>
> Summary:
> I support adoption.
>
> More words:
> I must admit to being somewhat uncomfortable with the potential for using this space to hide that actual course of a DoS -- yes, this is somewhat addressed in the Security Considerations, but that doesn't actually remove the problem.
> That said, the sad fact is that with so many networks not doing BCP38 you already have no faith in the source address of a packet IMO the benefits outweigh the risks.
>
> W
>
>

---

From: Xing Li <[email-masked]>
Date: Fri, 28 Oct 2011 07:48:29 +0800

Hi, Ray,

Thanks for your mial.

? 2011/10/27 4:04, Ray Hunter ??:
> I raised concerns about draft-xli-v6ops-ivi-icmp-address-00.txt when 
> it was originally discussed on this list last July.
>

Yes, we have all the records of the previous mails and we will update 
the draft. Thanks.

> IMHO Due consideration should be made to weigh up the likely 
> operational cost incurred because (many?) operators will have to 
> change a lot of operational filters (to avoid the very likely abuse of 
> this special range as a DDOS source) against the likely operational 
> benefit for the (few?) operators who have applied this technology.
>
> special purpose range (either RFC1918, or a privately assigned block 
> of public IPv4 addresses from existing space, which can be shared 
> between operators).
>
> Admittedly the alternatives are not very attractive. But neither is 
> the translation of ICMP messages into a packet that carries very 
> little value or information when observed outside of its own AS, which 
> is not traceable, and which could in fact become a danger thus 
> triggering a need for mass packet filter updates.
>

Due to the IPv4 address depletion, more and more IPv4/IPv6 translators 
are being deployed. We need a guideline for representing 
non-IPv4-translatable address as the source address in ICMP packets. 
Based on our operation experience, allocating a special IPv4 //24 is a 
reasonable choice. If we can move forward, there will be enough time for 
ISPs to update the filters.

Regards,

xing

---

From: Joel jaeggli <[email-masked]>
Date: Thu, 27 Oct 2011 16:53:50 -0700

> ISPs to update the filters.

with the properties for utilization described in the draft there'd be no
way in hell I'd accept these on the ingress to my network.

>>>> > 于 2011/10/14 5:52, Fred Baker 写道:
>>>>     
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: Fred Baker <[email-masked]>
Date: Fri, 28 Oct 2011 09:42:29 -0700

As I understand the proposal, this prefix would be used in ICMP but not in routing. It's a way to have ICMPv4 be able to represent an IPv6 address translated from ICMPv6. I understand that the prefix probably wants to be treated as a martian from a BGP filtering perspective, but if it's not advertised I'm not sure I see the down side in routing.

Help me out here?

On Oct 26, 2011, at 1:04 PM, Ray Hunter wrote:

> I raised concerns about draft-xli-v6ops-ivi-icmp-address-00.txt when it was originally discussed on this list last July.
> 
> There now seems to be a number of people on the list who see its benefit, and are supporting the draft.
> 
> IMHO Due consideration should be made to weigh up the likely operational cost incurred because (many?) operators will have to change a lot of operational filters (to avoid the very likely abuse of this special range as a DDOS source) against the likely operational benefit for the (few?) operators who have applied this technology.
> 
> There are alternatives available for address ranges to use as a source address of translations within the AS without assigning a new global special purpose range (either RFC1918, or a privately assigned block of public IPv4 addresses from existing space, which can be shared between operators).
> 
> Admittedly the alternatives are not very attractive. But neither is the translation of ICMP messages into a packet that carries very little value or information when observed outside of its own AS, which is not traceable, and which could in fact become a danger thus triggering a need for mass packet filter updates.
> 
> I asked at the time: can anyone think of any other example of a "one-way" special purpose packet that is allowed to leave the link, never mind the AS?  RFC1918 addresses are not allowed to cross inter-enterprise links (for good reasons).
> 
> Regards,
> RayH
> 
>> Subject: Re: [v6ops] Fwd: 82nd IETF DRAFT Agenda
>> From: Warren Kumari <[email-masked]>
>> Date: Wed, 26 Oct 2011 07:32:35 -0400
>> To: Xing Li <[email-masked]>
>> CC: "[email-masked] WG" <[email-masked]>, V6ops Chairs <[email-masked]>
>> Content-Transfer-Encoding: quoted-printable
>> Precedence: list
>> MIME-Version: 1.0 (Apple Message framework v1084)
>> References: <[email-masked]> <[email-masked]> <[email-masked]>
>> In-Reply-To: <[email-masked]>
>> Message-ID: <[email-masked]>
>> Content-Type: text/plain; charset=utf-8
>> Message: 1

---

From: Ray Hunter <[email-masked]>
Date: Fri, 28 Oct 2011 19:24:21 +0200

Yes it will be used for ICMP messages that probably are useful to 
translate from IPv6 to IPv4.
It might indeed help in MTU mismatch situations and be useful for 
debugging as is claimed in the draft.
I have no problem with that at all. I think the overall translation 
technology is very useful.

No the range won't be routed (for replies). This make it a one-way packet.

Yes it will be a martian from a routing perspective, so BGP should be 
safe. There should be no downside in routing.

The downside is in the packet ingress filters at the AS boundary.

For the proposal to be at all useful, the packet must not be treated as 
a martian by ingress filters.

IMHO This draft will create a packet that:
i) affects the behavior of nodes (it can contain ICMP too big messages)
ii) can be sent by anyone to anyone else containing any content
iii) there's no way of verifying the validity or integrity of the content
iv) there's no way of confirming the identity of the source (no 
non-repudiation)
v) it will be an officially sanctioned IETF solution
vi) there's no way for a remote 3rd party AS to trace the packet back to 
the source, except to the next hop AS via some sort of clever back 
scatter analysis or traffic flow record capture
vii) there's no registration of who has used this address range or who 
runs the translators = no abuse email or phone number to call when there 
are problems

In short, I'm not sure that I could design a better candidate packet to 
be able to conduct a DDOS if I tried.

So operational people are left with a binary choice:
Some people will not allow the special ICMP packet through their network 
ingress filters: making the proposal useless
Some people will allow the special ICMP packet through their network 
ingress filters: exposing themselves to potential DDOS attack.

So operationally speaking, the current proposal is lose lose.

I've got no problem at all if the proposal avoids these operational 
pitfalls e.g.
i) using a source address that is traceable using a GUA IPv4 range that 
has a registered owner per translator so that it can cross AS boundaries 
like any other packet,
ii) I wouldn't even mind too much operationally speaking if a bunch of 
AS's got together and agreed to share a single range between them, as 
long as one AS held the registration for the range and took 
responsibility for any operational problems. Others may take a stricter 
view, or
iii) using an RFC1918 range for the source address and confining the 
translated packet to be within an AS boundary.

regards,
RayH

Fred Baker wrote:
> As I understand the proposal, this prefix would be used in ICMP but 
> not in routing. It's a way to have ICMPv4 be able to represent an IPv6 
> address translated from ICMPv6. I understand that the prefix probably 
> wants to be treated as a martian from a BGP filtering perspective, but 
> if it's not advertised I'm not sure I see the down side in routing.
>
> Help me out here?