Inspired by the draft in the topic, I would like to get some advice on the following:
It seems that in mobileip wg, reflector attack scenarios were identified for routing headers in Savola's draft. One solution, which seems to me feasible to implement (no state needed), was to mandate segments left to 1 and check that the address in the routing header is owned by the receiving MN host. Seems these scenarios are not necessarily mobileip-specific. I am wondering, are routing headers in this wg considered a special-purpose mechanism that cannot be used? For home address options there are sections in Arkko's second draft in mobileip where it is recommended them always to be protected and (indirectly) to support both weak and strong authentication. MN-CN authentication is supposed to support weak authentication, a concept which was prompted by scalability concerns of the AD's. However, in mobileip version 15 there is an authentication sub-option, useful with weak authentication. This design can easily be re-used in implementation even with the home address option. Are these not concerns, other than tunneling, already addressed by the currently chosen solution? If these expressed concerns can be addressed by using existing extension headers, why not use them? BR, -Jari Brian Zill wrote: > > Francis is correct. The motivation behind the draft was the observation > that there are or have been (either currently being specified or > proposed) several different special-purpose mechanisms for what amounts > to optimized tunnels. Some of these turned out to have problematic > issues, especially when mixed and matched with other things. Issues > which would be much simpler to reason about and resolve if one had real > tunnels instead of these special-purpose mechanisms. The argument for > the special-purpose mechanisms has usually been that the duplicated > addresses in the tunnel headers is wasteful. This draft attempts to > eliminate that particular concern with a more straight-forward approach > to the problem. Hopefully it will serve as a basis for discussion, as > Francis suggests. > > --Brian > > > -----Original Message----- > > From: Pekka Savola [mailto:[EMAIL PROTECTED]] > > Sent: Tuesday, December 04, 2001 07:35 > > To: Francis Dupont > > Cc: Brian E Carpenter; Hesham Soliman (ERA); [EMAIL PROTECTED] > > Subject: Re: I-D ACTION:draft-deering-ipv6-encap-addr-deletion-00.txt > > > > On Tue, 4 Dec 2001, Francis Dupont wrote: > > > => I agree (this argument applies near each time where the > > > bandwidth is critical) but I believe the purpose is not to > > > save bandwidth but to replace special devices by a more > > > general one: > > > - replace one shot source routing by IPV6_NO_SRC > > > - replace home address option by IPV6_NO_DEST > > > There are already degenerated (i.e. optimizable) cases of > > > tunnel in mobility, IPsec, ... To have a general mechanism > > > is a good idea, at least as a basis for discussion. > > > > Exactly the point I was making. > > > > Saving bandwidth won't hurt, but that's definitely not the > > reason to do it. > > > > -- > > Pekka Savola "Tell me of difficulties surmounted, > > Netcore Oy not those you stumble over and fall" > > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to [EMAIL PROTECTED] > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] --------------------------------------------------------------------
