Francis wrote: > I wrote: > No, but the specification of MIPv6 should wait until the ingress > filtering > part is specified. > > => I don't see why? Or do you argue that the ingress filtering part > is impossible or very long to specify (obviously not)? The purpose > to move this thread to the IPv6 WG mailing-list is just to fix it > in parallel.
It's just that I haven't seen credible solution to distributed ingress filtering of packets with HAO that doesn't resort to have a global AAA infrastructure to solve the hard problem. I personally think we need solutions that don't required additional infrastcuture. > That is all the IETF need to worry about. > > => I disagree, the IETF need to worry about holes in the set of > standards track RFCs we have already issued (the RFCs) and missed (holes). > (this should not happen but we know it's happened) Sure, in addition to make sure that new stuff doesn't have holes we either need to fix or deprecate existing stuff with security holes. I don't think I said anything to the contrary. > For the IETF I think this means that we should not issue a proposed > standard > (e.g. for MIPv6) with a hole (e.g. assuming that ingress filtering will be > made aware of HAO). > > => I believe you'll have the same opinion about BU security too (i.e. > byebye RR :-). I don't understand the point and I don't understand the joke. Could you be more explicit? > If we want to go this path I think we need a community supported > > => supported = saying this is the solution or > supported = have implemented it or > supported = have deployed it > First is fine, second is possible (MIPv6 people will put pressure on > firewall people, IMHO firewall people need to be more aware of IPv6 > in general). The last one is out of the scope of the IETF. If youn read the whole sentence before interjecting the comments (it's below) you'll see it was about an RFC. BCP and Proposed standards are not required to be implemented and/or deployed in order to be publishes as such. > ingress filtering RFC (BCP or standards track) that handles HAO no > later than when MIPv6 becomes Proposed Standard. > > =. can I translate your argument in the network access control for HAO > documents should be available (or enough stable) before the MIPv6 one > in the same state? Yes, this is what I said several times now. No PS for MIPv6 with a security hole in my personal opinion. Means that a PS or BCP smart ingress filtering (set of) RFC need to exist at that time as MIPv6 becomes PS. > This is unrealistic for DIAMETER (because of the > AAA state), easy for RADIUS and out of the scope of the IETF for > firewalls (I am not a firewall expert, I only know that many commercial > firewalls have a network access control module... in fact the whole > idea is from a team with some firewall persons so I know the whole > thing was put in a commercial firewall more than two years ago but > the @#$... people don't believe there is a market, grr...). Above you said it wouldn't delay MIPv6 to do this (because of it being done in parallel) but now you seem to say it would delay it because of various reaons. So you seem to agree with me about the delay? > PS: we are losing time: keep or kill the triangular routing? I say: Remove the unauthenticated and unauthorized use of HAO which has the effect that tringular routing isn't an option. The only options are bidirectional tunneling through the HA and route optimization. Erik -------------------------------------------------------------------- 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] --------------------------------------------------------------------
