In your previous mail you wrote: 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.
=> so you'll be very happy when you'll read my draft which relies only on *enough* of any kind of network access control (even passive one, aka BU/BA snooping which can have the favour of firewall folk). I personally think we need solutions that don't required additional infrastcuture. => we agree. > 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. => your statement could suggest the IETF doesn't need to worry about holes in already published standard track RFCs (we agree this is *not* the case). > 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? => RR is known to be a bit weak from a security point of view so as a MITM vulnerability can be considered as a hole, your opinion should be in disfavour of RR, isn't it? (smile again) > 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. => I apologize: I was afraid of overinterpretations of the term supported. > =< 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 needs to exist at that time as MIPv6 becomes PS. => thanks, now there is no possible ambiguities about your opinion. BTW I fully agree with you about this point. > 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 reasons. => where are the reasons (in document publication, cf above) of delays? This can only be about the connection between network access controls and firewalls: - there is no IETF protocol about this - it seems the current consensus is this is not in the IETF scope - this exists, in general in the purpose to be applied to remote and/or mobile users, for instance http://www.evidian.com/accessmaster/netwall/features.htm#Broad In many AAA and PANA drafts (including mine :-), there are references about when the terminal is authentified the firewall is opened for it (i.e. authorization is "to access to the Internet"). I can't find details about how this is done, can some firewall folk help us? (if you know some, can you forward this to them) So you seem to agree with me about the delay? => one thing we agree is we don't want 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. => so we disagree only about the necessity to remove the unauthenticated and unauthorized use of HAO (my argument is there is no such necessity about source address themselves). Thanks [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] --------------------------------------------------------------------
