[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [IMRG] Requirements for IMP

 Jon, please see some comments inline on some of your points.
When specific protocol aspects are discussed, I refer to
http://www.ietf.org/internet-drafts/draft-mcgregor-ipmp-03.txt
Maurizio

jon bennett wrote:

A number of times in this discussion a question has been raised as to
whether or not a certain facility was required in IMP. I think it
would be useful to start exploring what the requirements should be as
that will enable us see which bits of functionality there is agreement
on and which bits there is disagreement on. It will also hopefully
identify those areas where that have not been addressed at all as of yet.

I have listed the topics below so that people who might only be
interested in one or two of them can skip to the ones they care about
without reading the whole message. My hope is for as many people as
possible to comment on these since we can't improve the protocol
without feedback.

The list of items below is not intended to be complete, rather it is a
starting point as well as a list of items for which some answers lead
to perhaps non-obvious implications, some are items which are simply
contentious and some items which have been assumed to be required but
perhaps should not be required.

1) Measurement of the Reverse Path
2) Length of Measurable Path
3) Host Processing, Raw Sockets or Ports
4) IP Address in Path Record
5) Timestamp in Path Record
6) TTL in the path record
7) Information Request
8) Information Request part of IMP or a UDP Based Service
9) Redirection


----------------------------------------------------------------

1) Measurement of the Reverse Path

Is it a requirement of IMP to measure the reverse path? Well 1/2 the
time the problem will be in the reverse path so this seems like an
obvious "Yes".

An implication of this is that it (on average) doubles the number of
records that need to fit in the packet.

Is it a requirement of IMP to measure a broken reverse path? Well when
paths break 1/2 the time it will be in the reverse path so this would
also seem to be a "Yes".

This has a rather more significant implication, if the reverse path is
broken how do you get the IMP packet back to see where the break is? 
Isn't there the same problem if the break is in the "forward" path?



2) Length of Measurable Path

Is it a requirement of IMP to be able to measure paths of any length?
If the path works (as opposed to loops) then we would want to measure
all of it regardless of length so the answer would seem to be "Yes".

An implication of this is that for small packet sizes and/or reverse
path measurements some method of preventing the first N hops from
always filling the packet is needed, otherwise only the first N hops
will ever be measurable.
I think this feature is needed. More in general, I think that what is needed is the ability of selectively enabling/disabling IPMP routers to insert path records.
The main two reasons I see for it to be useful are the following.

1) It would provide a way to directly test whether it's true or not that the full processing of IPMP packets is done as if corresponding ordinary packets were processed (requirement of http://www.ietf.org/internet-drafts/draft-mcgregor-ipmp-03.txt, sec. 4.4).
Suppose you have N_f IPMP aware routers in the forward path and N_r in the reverse one. Starting from a situation where only the echoing router inserts a path record (and where we measure of a delay D_f_0 in the forward path and D_r_0 in the rewerse one), one could selectively activate the measurements on some of them, measure a D_f_ 1 and D_r_1, then further increase the percentage of IPMP routers allowed to insert path records, etc.
Ideally, if all the IPMP aware routers complied to the mentioned sec. 4.4 requirement

"A forwarding system SHOULD NOT insert a path record if it
cannot modify the packet in the same processing stream that any
other packet would take. This is to avoid the measurement path
being significantly different than that taken by a regular packet,
and to reduce opportunities for denial of service attacks (see
Section 4.5)."

then all D_f_i = D_f_0 (*) for all i, and similarly for the reverse path. Otherwise, by repeating multiple tests, the critical routers could be found. (*) equal accoding to some statistical test, to be defined.

Of course, these tests would be only useful to evidence if an IPMP aware router takes much more time to insert a path record than just realize it's not allowed to do so and forward the packet. It doesn't say anything about how similar the treatment of an IPMP packet is wrt the one of a corresponding ordinary packet.

2) In a scenario where a set of mesurements are continuously running between several netwok end points, there's no use in always having a full view of the path if the end-to-end performance metric under observation is within an admittable range. In case the metric breaks a threshold, one could immagine to gradually increase the number of IPMP routers along the path inserting path records. Non-affected paths wouldn't place additional measurement burden on IPMP routers.

As regards the implementation of such a selection, one can immagine different possibilities, trading off simplicity and selectivity.
E.g. putting two explicit 1 byte start/end indexes in the IPMP header (an IPMP router can write a path record only if the TTL of the packet is within the range) or using a very few bits (an IPMP can write a paket only if the TLL ends with the same bit pattern).
3) Host Processing, Raw Sockets or Ports

Is is a requirement of IMP that applications/servers send and receive
IMP packets over raw sockets or should port numbers to be provided to
allow the use of bound sockets? While there may be performance
concerns that would recommend against raw sockets I think the security
implications are probably more compelling. Generally raw sockets
require root/administrative privileges to open. This greatly limits
the deployment options for experimenting with IMP applications;

http://www.merit.edu/mail.archives/nanog/2001-02/msg00829.html

If the OS did not require such privileges then any application on the
host can send/receive IMP packets greatly complicating the job of
firewalls. If IMP has port numbers (and there is a 'well known' echo
port) if a site ensures that a trusted echo server is bound to the
well known port on all its hosts then it can configure its firewalls to
only allow in traffic to the well known port, without providing a
covert channel through the firewall.

Also having ports would allow operators to run private echo servers on
non-well known ports which would make them less vulnerable to DOS
attacks (demuxing on port numbers being much more efficient than by
pattern matching filters). (if the private servers only echoed packets
from the local subnet/NOC hosts/containing a special 'cookie' then the
private server could not be found by port scanning.

Finally since having port numbers does not preclude using raw sockets
if that is desired, but not having them requires it, it would seem
that IMP should have port numbers.



4) IP Address in Path Record

Should IMP require that devices put their IP address in the path record?
If by IP address we mean a "globally routable IP address", then the
answer would have to be "No" since routers behind a firewall/NAT only
have a private IP address, but we would not want them to be unable to
insert a path record because of this. Additionally it is easy to see
for security reasons that a site may not wish to reveal the topology
of the network behind its firewall (and an ISP may not wish to reveal
the topology of the interior of its network) but that does not mean we
don't want to know about the existence and/or properties of devices on
the path.

If we don't require IP addresses what do we require? AS numbers? If
you have one that would be reasonable. If not, then what? Requiring
some sort of 'unique' ID probably raises the issue of topology
discovery again. So it would seem that IMP should not require any
address at all to be in the path record (except AS num if
applicable).

In general one would want devices to put an IP address in the record if
possible, but the protocol must work if they do not. 


5) Timestamp in Path Record

Must IMP require that a timestamp always be included in the path
record? Probably not. Without the timestamp the path record is static
but for the 8 bit TTL making the incremental checksum update much
easier.





It is also possible that in existing equipment for which IMP
support is added that there is no clock available at the location
where path records are inserted. Now in the case where the device can
not insert a timestamp do we require the timestamp field to be
included (0 filled?) or do we allow it to be omitted? If the timestamp
field is omitted then more records can fit in a packet. In the case
where IMP is being used as (reverse) traceroute it might make sense to
allow the sender to request the omission of the timestamp for this
reason. Obviously the desired behavior in the general case is for
there to be a timestamp if possible and desired by the sender.


6) TTL in the path record

Should path records be required to contain the TTL value of the packet
when the record is inserted? I believe that the answer is "Yes". It
will be a long time before all devices implement IMP, understanding
which hops in the path have inserted records will be very important
for understanding how useful the returned information is. A good
example would be were a packet crosses from one ISP to another, being
able to determine that there are no unrecorded hops between the last
record from ISP A, and the first from ISP B allows the packet to serve
as a valid measurement of the two separate networks. If there might be
an unknown device between the two measurements then it would not be
possible to know where one ISP's network ended and the others began.
Since the TTL occurs very early in the IP packet and is only 8 bits
the effort required to support it in the checksum update is minimal
compared to the benefit of having it.



7) Information Request Required

Is the information request packet required? Will the protocol work
without it? I would argue that the information request packet can not
be required and that the protocol must work without it. There are a
number of reasons for this. Firstly having identified that we can not
require that path records contain a globally routable IP address, if
the information request packet is required for proper operation then
the protocol is already broken for all routers behind a
firewall/ALG/NAT. Secondly since the information request requires more
processing effort than an echo request it is highly unlikely that a
router will be able to process even close to as many info requests per
second as echo requests. If each echo request requires an info request
then the info request may have to be sent repeatedly to get an answer
back, further increasing the load on router. Thirdly since the info
request is harder to process it provides a DOS attack against the IMP
echo protocol, i.e. you attack the point of service for the info
requests which renders the echo requests unusable





While it may be allowed so it can provide useful additional features 
it does not seem

that the Information Request can be required for proper operation of

the protocol. 


My understanding of the role of the Information Request in

http://www.ietf.org/internet-drafts/draft-mcgregor-ipmp-03.txt

is that it  is  used to get better confidence of what the echo request 
packet carry. There's no reqirement for Information Request to be 
processed like ordinary data packet, and in sec. 4.5 it's said that a 
rate limitation or a low processing prioriy can be used as a protection 
from potential DoS attacks exploiting the Information Request.

I agree, however, that the protocol should not make Echo Requests depend 
on Information Request, i.e. the protocol should work anyway in absence 
or with a low rate of Information Requests (but an application could 
then declare the measurements as "unreliable").






8)Information Request part of IMP or a UDP Based Service

Should the information request be part of IMP itself or should it be
just a protocol exchanged over a UDP port? The only example of a need
for the information request to be part of IMP that I have come up with
would be in the case of a broken reverse path (and assuming a yes
answer to #9 below) that one could use IMP redirection to be able to
get a response to an info request from hosts and routers on the
reverse path. It is not clear to me this is enough of a reason to
include it in the protocol itself as opposed to specifying it as a UDP
based service.


9) Redirection

Does IMP need a redirection function similar to the IP Loose Source
Route option? Yes it does. For IMP to be useful in the context of
network operations the ability to bounce the echo request off of other
routers and hosts is clearly required, for an explanation see;

http://www.merit.edu/mail.archives/nanog/2002-02/msg00247.html

That the redirection should be built into IMP can be derived from two
points, firstly it allows us to include security measures not present
in LSRR which eliminate some of the spoofing concerns people have with
the general availability of LSRR. Second since the processing of
packets with IP options is often not in the same path as un-option-ed
packets it would interfere with the desired operation of IMP to use
source routing headers. Thirdly when trying to trace the path taken by
packets belonging to an application, if the IMP packet contained header
options then it would be very likely to not match any application
specific filters, or to have a different hash value when picking the
output link in the case of ECMP routing. Fourth, without redirection
there is no way to probe a broken reverse path. So it seems the
redirection is required and that it must be supported within the
protocol itself.



_______________________________________________
IMRG mailing list
IMRG@ietf.org
https://www1.ietf.org/mailman/listinfo/imrg







_______________________________________________
IMRG mailing list
IMRG@ietf.org
https://www1.ietf.org/mailman/listinfo/imrg