In your previous mail you 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.
If we (the IETF) really care about security we need to make sure that we don't create holes in the set of standards track RFCs we issue. => I agree but in this case the target is explicitely "not introduce significant new vulnerabilities that are not present in IPv4 today". The new vulnerability has not be proved to be significant and the proposed reply is designed to get back to the IPv4 situation (where the reply to the threat, I have to say it again, is a BCP). 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) 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 :-). 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. ingress filtering RFC (BCP or standards track) that handles HAO no later than when MIPv6 becomes Proposed Standard. I don't think we should use the fact that 1) there are IPv6 products with incomplete security and/or 2) existing IPv6 operational networks have incomplete security as arguments that we can have an IPv6 story where the standards have security holes. Even if we say "we'll fill that hole really => I never use the "we'll fill" argument. My idea is "we can fill/we know how to fill" in order to not slow down MIPv6 specifications. To move the thread to the IPv6 WG is for the same purpose. quickly by later producing an HAO aware ingress filtering RFC" or something similar. It seems like the IETF pieces (RFCs) that need to be completed to have complete (i.e. not security holes in the combination of specs) specification for network access control is sizeable: some fireall spec (perhaps informational), some radius and diameter extensions. => we need only some radius extensions (diameter extensions already exist (as an author of one of the diameter for MIPv6 drafts, I may claim this), firewall specs are not really in the scope of the IETF). Of course if diameter for MIPv6 becomes a real AAA WG activity (this is in the charter of AAA, the AAA/mobility RFC is very well written (it makes no difference between IPv4 and IPv6), but AAA people believe MIPv6 will be ready in many months/years). This sounds like more delay for MIPv6 to me. => not if it is done in parallel. The two-phase approach removes this delay. => by dropping in practice the second phase, no thanks! > Seems like this requires a two-phase approach: phase 1 before it is > available and phase 2 when/if it become available. > > => you are asking what will happen after some kilometers in a deep fog: > today only IPv6 raw protocol is available, not mobile IPv6, IPv6 ingress > filtering, IPv6 firewalls, ... You're confusing specifications, products, and deployed practice. => no, I just reject all arguments based on what will happen in the future at the exception that we want to get IPv6 smart ingress filtering deployed not after than mobile IPv6. The IETF has no control over deployment, its control is only over document publication, so the only thing we can ask is to provide smart ingress filtering documents before MIPv6 (we can do a bit more because we can implement them too). People can build ingress filtering and firewalls for IPv6 today without waiting for a specification from the IETF. That wouldn't be true if we issue a MIPv6 specification which, in order to avoid ingress filtering, depends on some yet to be written RFCs that specify network access control for HAO. =. 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? 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...). But we don't want to delay MIPv6 any more than we need to. => my purpose was never to delay MIPv6 but we obviously disagree about what kind of stuff can be removed safely (i.e. with the possibility to put them back after) from MIPv6 in order to speed it up. Regards [EMAIL PROTECTED] PS: we are losing time: keep or kill the triangular routing? -------------------------------------------------------------------- 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] --------------------------------------------------------------------
