> => we don't need to wait because mobile IPv6 is not yet fully specified. > IMHO the only thing we need is to be ready and the first step should > be to get (traditional) ingress filtering and firewalls with IPv6 support > (or do you suggest to stop IPv6 until they are implemented and deployed?)
No, but the specification of MIPv6 should wait until the ingress filtering part is specified. 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. That is all the IETF need to worry about. (Others need to worry about complete security of products and a third set of folks need to worry about the security of their operational network using those products.) 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). If we want to go this path I think we need a community supported 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 quickly by later producing an HAO aware ingress filtering RFC" or something similar. > If not, what do you propose to do in the interim until network > access control for HAO is available? > > => decide if we keep or kill the triangular routing. In parallel (because > even if the triangular routing is killed there are still similar mechanisms > based on tunnels with the same security issue) give this idea to > network access control people (both RADIUS/DIAMETER and firewall) in > order to know what concrete proposal we can/should do (for instance a > new RADIUS attribute for IPv6 inner source address declaration). IMHO > this second part is mainly not technical (i.e. out of the scope of IETF). 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. This sounds like more delay for MIPv6 to me. The two-phase approach removes this delay. > Seems like this requires a two-phase approach: phase 1 before it is > available and phase 2 when/if it become available. > > => you are acking 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 practise. 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. > => mobile IPv6 is not yet in last call, in fact we don't know if it will be > this year. So we only need a paper solution against the future and > potential minor security threat of HAO with ingress filtering. But we don't want to delay MIPv6 any more than we need to. 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] --------------------------------------------------------------------
