Re: [Int-area] I-D Action: draft-shen-traceroute-ping-ext-03.txt

[Warren Kumari <[e-mail]>]

On Jan 4, 2012, at 6:32 PM, Naiming Shen wrote:

> 
> Hi Thomas,
> 
> On Jan 4, 2012, at 2:43 PM, Thomas Narten wrote:
> 
>> Carlos Pignataro <[e-mail]> writes:
>> 
>>> Hi Ron,
>> 
>>> Thanks for the comments, please see inline.
>> 
>>> On 1/4/2012 2:01 PM, Ronald Bonica wrote:
>>>> Authors,
>> 
>>>> This draft changes the meaning of bits in the ICMP, TCP and UDP
>>>> headers. Therefore, if published, it would UPDATE RFCs 792, 793
>>>> and 768. You may find that a very high bar to clear!
>> 
>>> This draft is not really changing the meaning of bits in the ICMP, TCP,
>>> and UDP headers.
>> 
>> Actually, it sort of does and sort of doesn't. It's not black and
>> white.
>> 
>> True, it doesn't redefine TCP/UDP headers in any way.
>> 
>> However, it does call for the placement of "magic values" within an
>> arbitrary TCP/UDP packet. When generating ICMP responses to such
>> packets, when the magic value is present, ICMP behaves differently
>> than before. That is a change.
>> 
>> Also, this technique by defintion encourages the creation of "test" or
>> "probe" TCP/UDP packets as part of network debugging (or even regular
>> monitoring). Should those probe packets "escape" and actually be
>> delivered to the destinations as defined by the TCP/IP headers and
>> port numbers, there may be unintended consequences to applications
>> that happen to be using those port numbers already. Oops.
>> 
>> Consequently, use of this technique may actually cause collateral
>> damage to existing, deployed applications. Maybe not a big risk, but a
>> risk nonetheless. 
> 
> This draft actually does not change those attributes. The current traceroute/ping
> application has already picked up those high port numbers, and already has used the
> source port and id field for some private number no one else cares. Let's say if this
> draft is using a fixed location scheme, then there is no change to any of that.
> 
>> 
>> I would feel much more comfortable with this technique if it could be
>> guaranteed that when probe packets are generated, they do not go
>> "anywhere" in the Internet, but stay within (say) a domain where
>> debugging is necessary. I.e, I could see an ISP doing this within
>> their network, but also preventing such packets from leaving their
>> networks.
>> 
>> Not sure how to enforce this though...
> 
> Let's say if I'm using this extension in an particular ISP only meant to get
> some private info for our management stations. First I think the operator
> usually specify the destination to be within the range of the network they
> want; secondly, even if not, the packet actually goes off the network, there
> is not much harm done, those off-net stations should not supply those
> private information or they probably don't care. yes, it will waste someone's
> cpu and bandwidth resource,

Speaking as a "someone", I don't want you wasting my cpu and bandwidth resources.

> but it's also due to the operator didn't check
> the address carefully.


You are looking at this from the wrong side.

I run a large network, with many many devices. I allow ping (and traceroute) into my network because lots of *customers* ping / traceroute to test their connectivity, especially if they think there is some sort of issue. I allow these packets because it benefits me and the customers, and the benefits outweigh the costs.

I (and I believe the other operators speaking) are not concerned that *we* accidentally leak these extended packets (because a: this so isn't something we want to run, b: we have no reason to destine these outside our networks, c: can filter these outbound if we want really easily and d: are relatively small in number), the big concern is that *large numbers* of *users* start sending these at our devices (or, attackers start sending them intentionally, and causing more work for my devices).

If ping processing goes from being a negligible use of resources to something noticeable, the only reasonable solution I have is "deny icmp any any echo" on edge. 
This is not good for me, this is not good for my customers, this is not good for the Internet at large.

This is why we are concerned about having protocols we have to (or are expected to) allow in from the Internet and would prefer it to be in a separate protocol that can be *easily* filtered at the edge of the network. If the proposal was to carry this in a protocol with a well known port (like, oh, I dunno, UDP/161) that I can filter I wouldn't care.

It is *not* an accident that:
snmpget -c public 209.85.254.233 SNMPv2-MIB::sysDescr.0
does not give you a response.

W

> 
> I agree to focus on the concept or framework is the key for now.
> 
> thanks.
> - Naiming
> 
>> 
>> Now, I brought up this document because over in Trill, OAM is being
>> discussed, and the approach outlined in
>> draft-shen-traceroute-ping-ext-03.txt was cited as something that
>> might be useful to leverage. In a Trill environment, it might well be
>> possible to ensure that no OAM packet leaves a Trill campus. In that
>> case, the above concern largely goes away.
>> 
>> In terms of next steps, I'd suggest thinking of two kinds of issues,
>> and dealing with them separately.
>> 
>> First, is the concept OK?
>> 
>> Second, is the actual format of the packet, the encoding details,
>> etc. right? I personally don't want to bother discussing the latter
>> details unless we decide the basic concept itself  is workable and a
>> good way forward.
>> 
>> And my own opinion, based on the discussion so far leaves me on the
>> fence. I'm not yet convinced that the idea itself as defined in this
>> document makes sense.  We need to listen very carefully to what
>> operators are saying. We want to provide them with tools that will
>> actually help them. If they have concerns (which they do), and we
>> brush them off, we may well end up spending a lot of time developing a
>> solution that they won't ever get used. That's not a good use of
>> anyone's time/effort.
>> 
>> Thomas
>> 
>> _______________________________________________
>> Int-area mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/int-area
> 
> _______________________________________________
> Int-area mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/int-area
> 


---
Don't be impressed with unintelligible stuff said condescendingly .
    -- Radia Perlman.

Warren Kumari
[e-mail]