Re: [v6ops] Fwd: Request for WG Adoption of draft-xli-v6ops-ivi-icmp-address-00

[Xing Li <[e-mail]>]

? 2011/7/29 4:09, Ray Hunter ??:
> Following all IMVHO.
>
> Sorry I'm not convinced. It isn't just packet firewalls that are going 
> to need/want to drop these packets.
>
> Imagine I'm acting as the responsible owner of an AS. Under this 
> proposal I have all downside and no upside. Let me explain.....
>
> If this range is going to be used for sourcing DDOS traffic (and I 
> strongly suspect it will), and it isn't going to be possible to easily 
> isolate or debug which upstream AS or site or network interface or 
> customer device was the source of that bad traffic, then the packets 
> need to get dropped at the AS border and every other uncontrolled 
> entry point on the network that connects to third party managed 
> devices. I don't want untraceable packets sourced by someone else 
> floating around in my network and potentially causing trouble tickets 
> / problems that cost my staff's and my management time.
>
> Equally, if I'm acting as a responsible network operator, I don't want 
> to act as a transit on a potential DDOS attack to other AS'es to avoid 
> hurting my own good reputation (the downstream AS will have no idea if 
> the DDOS attack originated in my AS, or another upstream AS, and my AS 
> was just acting as a transit). Either way I'd look daft, and the DDOS 
> attack would be difficult or impossible to trace: which is precisely 
> one reason why ingress filters were recommended in the first place.
>
> So all ingress and egress filters will probably end up dropping the 
> new special range, and no one will be any the wiser.
>
> In which case, using the special /24 shared range is actually less 
> useful compared to just using a locally significant and existing  
> RFC1918 range of addresses for each translator in my network for the 
> translation of IMCPv6 messages sourced behind my own IPv6/IPv4 
> translator(s) IMHO. At least then I and my staff would know exactly 
> which translator the ICMP message came from in my AS if there was more 
> than one translator present, and I'd be able to take corrective action 
> if necessary.  Plus I'd know for certain if I saw such RFC1918 sourced 
> ICMP traffic in my AS that they weren't sourced from someone else's 
> translator in another AS that I don't even manage. And yes packets 
> with RFC1918 source-addresses would also be dropped at the AS border, 
> as today.

Actually they are the configuration choices
(1)    If the network owner of the translator(s) has enough public IPv4 
address, he/she can configure the translator(s) using the public IPv4 
for it. However, for many networks, they cannot afford to do so due to 
the IPv4 address depletion.
(2)    The network owner can use RFC1918 for this. However, if the 
network has already use RFC1918 addresses, careful network plan is 
needed. In addition, this cannot be used to identify the IPv4/IPv6 
translation.
(3)    The special /24 can be thought as a "new block of RFC1918" in 
this sense, i.e. the routing behavior is similar. However, this block is 
targeting the IPv4/IPv6 translation, and can be configured specifically 
for it. This provides more control for the network administrator. The 
drawback for this method is that the network administrators needs to 
update the acl list for this special block. However, we believe it is 
worth the effort for the transition.

For your reference, there were some discussions in the earlier version 
of this draft, see  
http://tools.ietf.org/html/draft-xli-behave-icmp-address-02 If people 
think we need more discussion like this, we can put the discussion in 
the appendix of this document.

Regards,

xing



>
> regards,
> RayH
>
>
> Xing Li wrote:
>> Hi, Ray,
>>
>> ? 2011/7/28 10:52, Ray Hunter ??:
>>> The concern would be that the special /24 is creating a new range that:
>>>
>>> - carries ICMP control messages, which could also be used to attempt 
>>> to alter a senders' behavior
>>> - is shared between multiple providers
>>> - is not traceable
>>
>> When the special /24 is used, it can identify that the ICMP messages 
>> are generated in IPv6.
>>> - should not be filtered at AS boundaries
>>>
>>> which could grant an attacker a perfect set of source addresses for 
>>> mounting a DDOS attack.
>>>
>>> Yes the range isn't routable as a destination, but that possibly 
>>> makes it even worse, as the target of any DDOS sourced from this 
>>> range would have absolutely no idea who was sending them the huge 
>>> volume of junk packets, except by incoming interface at the AS 
>>> boundary. I see no reason why a network operator would want to 
>>> accept such a packet from another AS into their network, so they'll 
>>> basically get filtered everywhere after the very first attack IMHO.
>>
>> As partially discussed in previous mail. This will not introduce new 
>> issues compared with using RFC1918 space. In Section 6 of this draft says
>>
>> 6.  Security Considerations
>>
>>     The use of an address for source addresses in ICMP packets is
>>     considered "safe" in so far as ICMP packets are not intended to
>>     generate responses directed to the source address.
>>
>>     However it is possible to use this address as a means of gaining
>>     anonymity when launching a denial of service attacks by using this
>>     address as the source address for other forms of malicious traffic.
>>     Packet firewall filters should be configured to treat addresses in
>>     the IANA-assigned /24 network as martian addresses by discarding all
>>     non-ICMP packets that use the IANA-assigned /24 network as a source
>>     address, and all packets that use the IANA-assigned /24 network as a
>>     destination address.
>>
>> Regards,
>>
>> xing
>>
>>    
>>
>>> regards,
>>> RayH
>>>
>>> Fred Baker wrote:
>>>> On Jul 27, 2011, at 4:14 PM, Ray Hunter wrote:
>>>>
>>>>> Am I permitted to ask some dumb questions about this draft since 
>>>>> it seems to be urgent?
>>>>
>>>> Certainly. I will ask the authors to respond to them.
>>>>
>>>>> The draft talks about translating IPv6 ICMPv6 responses back to a 
>>>>> special shared /24 public IPv4 source range where responses are 
>>>>> not 1:1 IPv6 source - IPv4 source mappable (presumably because 
>>>>> network links and equipment on the IPv6 side are using IPv6 space 
>>>>> from outside the mapped range).
>>>>>
>>>>> Don't we have this situation already when traversing multiple IPv4 
>>>>> networks using overlapping RFC1918 IPv4 address ranges e.g. on WAN 
>>>>> links?
>>>>>
>>>>> In that case doesn't ICMP just have to live with an RFC1918 source 
>>>>> address, and no one seems to have complained too bitterly so far?
>>>>>
>>>>> What's so special about this new IPv6 mapped situation that is 
>>>>> different to the existing situation of overlapping RFC 1918 
>>>>> addresses used by multiple providers, where it's already unclear 
>>>>> which unique node on the path generated the ICMP message, and 
>>>>> where uRPF filters would already be an issue?
>>>>>
>>>>> i.e. why should the ICMP messages just not be dropped in this case 
>>>>> at the AS border, or be sent with RFC 1918 source addresses within 
>>>>> an AS, or be sent using a source address from a globally unique 
>>>>> (/24) sub-range of the existing provider IPv4 space assigned to 
>>>>> the translator if they are so important?
>>>>>
>>>>> I'm sorry, and maybe it's me being totally dumb, but I just don't 
>>>>> see the added value of a "special" /24 shared amongst multiple 
>>>>> providers, especially if there are possibly multiple translators 
>>>>> and multiple providers on a path. It just doesn't seem to give any 
>>>>> significant extra information to the intended recipient, and if 
>>>>> anything may lead to more confusion. 128 into 32 doesn't go. End 
>>>>> of story.
>>>>>
>>>>> regards,
>>>>> RayH
>>>>>
>>>>>> Subject:
>>>>>> [v6ops] Fwd: Request for WG Adoption of 
>>>>>> draft-xli-v6ops-ivi-icmp-address-00
>>>>>> From:
>>>>>> Fred Baker <[e-mail]>
>>>>>> Date:
>>>>>> Wed, 27 Jul 2011 14:40:59 -0400
>>>>>>
>>>>>> To:
>>>>>> IPv6 Operations <[e-mail]>
>>>>>>
>>>>>> Content-Transfer-Encoding:
>>>>>> quoted-printable
>>>>>> Precedence:
>>>>>> list
>>>>>> MIME-Version:
>>>>>> 1.0 (Apple Message framework v1084)
>>>>>> References:
>>>>>> <[e-mail]>
>>>>>> Message-ID:
>>>>>> <[e-mail]>
>>>>>> Content-Type:
>>>>>> text/plain; charset=us-ascii
>>>>>> Message:
>>>>>> 6
>>>>>>
>>>>>>
>>>>>> Folks: the chairs are in receipt of this note. Please read the draft and comment.
>>>>>>
>>>>>> In short, the draft requests an IPv4 prefix to be used in ICMPv4 to refer to IPv6 routers on the far side of a translator. In the reverse case, ICMPv6 would translate the address to an IPv4-embedded address as defined in RFC 6145 (an IPv6 address containing and statelessly translatable to an IPv4 address). If we buy off on it - and that's a discussion we should have on this list - Ron can walk it through the IESG and get the assignment.
>>>>>>
>>>>>> Begin forwarded message:
>>>>>>
>>>>>>    
>>>>>>> >  From: Xing Li<[e-mail]>
>>>>>>> >  Date: July 26, 2011 10:36:32 AM EDT
>>>>>>> >  To:[e-mail]
>>>>>>> >  Cc:[e-mail],[e-mail]
>>>>>>> >  Subject: Request for WG Adoption of draft-xli-v6ops-ivi-icmp-address-00
>>>>>>> >  
>>>>>>> >  Hi V6ops Chairs,
>>>>>>> >  
>>>>>>> >  The authors of draft-xli-v6ops-ivi-icmp-address-00 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 to allow this address mapping to take place using a protocol-specific designated address block in IPv4.
>>>>>>> >  
>>>>>>> >  The authors are hopeful that this will not require any valuable face-to-face WG time at IETF 81 and the WG's consideration of this document can be undertaken entirely on the mailing list.
>>>>>>> >  
>>>>>>> >  regards,
>>>>>>> >  
>>>>>>> >  Xing Li
>>>>>>> >  
>>>>>>> >  
>>>>>>> >  
>>>>>>> >  
>>>>>>>      
>>>
>>>
>>> _______________________________________________
>>> v6ops mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/v6ops
>>>      
>