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

Re: IETF multihoming powder: just add IPv6 and stir

On woensdag, mei 14, 2003, at 08:30 Europe/Amsterdam, Masataka Ohta wrote:

Unless the source address is already a valid address assigned by the
ISP you're forwarding the packet to (which can't by definition always
be the case in a locator/identifier scheme),



That's why I overviewed in draft-ohta-e2e-multihoming-03.txt:





   However, to enable source address filtering to discard packets with
   source addresses not belonging to an ISP, it is useful to enable a
   host, not some intelligent intermediate router, select a source
   address compatible with an outgoing ISP.




Does it really matter who does it? This should be something we leave up 
to the implementers, if at all possible. However, if you want to get 
this deployed while the century is still young you'll have to make the 
hosts do it if the routers can't.




   For that purpose, intra
   domain routing protocols should maintain routing table entries with
   not only preference values of an external routes, but also proper
   prefixes to be selected for source addresses, if the entries are
   chosen by a host.




No way. First of all having a routing table in each host is a huge 
waste of resources. Second, why use fifth hand information if a host 
can simply send some packets and see if they make it through? That's 
much more effective and light-weight at the expense of some only a few 
otherwise unnecessary end-to-end packets. Routing protocols seldom know 
which paths are good. They barely know how to avoid the very bad and 
non-functioning ones.




The solutions should be end to end that complex functionality must
be performed only on hosts.




I agree in principle. However, if we can give people the option to 
offload this to a middlebox if they so desire, that's a plus. (Which is 
a very different thing from requiring middleboxes or requiring routers 
or other non-middlebox boxes in the middle to do it.)




Hosts needs help from routing protocols.




That's the same logic as suing a lawyer. At the surface it seems to 
make sense but you really don't want to do it if you can avoid it.




However, with multiple addresses to an interface, selection of source
address/locator can be performed properly only with the help from
routing protocol, which is a reason why IPv6 is broken in
source address selection.




The trouble with current transport protocols is that once you've 
selected your source address you can't change it. So we change it and 
then listen for ICMP messages to see when we have the wrong source 
address.



Or you can turn the whole thing around and decide if the host is going 
to use a source address that belongs to ISP A, well, then we have to 
send this packet out over ISP A. That way we don't even need routing 
tables in routers.  :-)




you need to rewrite it in
order to get through ingress filtering and to be able to receive ICMP
messages.





No. See above.




Note that I was taking no position about where the rewriting happens: 
this may very well be done inside the source host.




Remember that path MTU discovery is pretty much mandatory in
IPv6 so you need those ICMPs.





No. PMTUD is one, among many, of a useless feature of IPv6.



Why is it useless?




Just send packets not loger than 1280B.




That's unacceptable.



In fact, we need to go even further and implement functionality in 
neighbor discovery to enable the use of jumboframes between two hosts 
that support them even though other hosts on the same subnet may not.




Ingress filtering is important to keep
denial of service attacks in check to at least some degree.





Ingress? Do you mean egress?




No. I can't trust my neighbors to send me only good packets, so I have 
to make sure this is the case myself.




You can't filter an ICMP packet generated for a packet with forged
source address, because the ICMP packet has valid source and
destination addresses.




That's why we must filter the original packet with the forged source 
address. Then there is no trouble with ICMP messages generated for it.




Note that an alternative proposal is to let routers have complex
packet tracing functionality.




I assume you mean tracing forged sources? This done for only very few 
packets so it doesn't get in the way of regular operation.