[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: I-D ACTION:draft-savola-v6ops-6to4-security-02.txt
Any tunnel creates embedded verification needs unless all parameters are
secure to build it or there are checks to do decap at non-secure points
in the path. This is not indicative of 6-to-4, but of tunnels. But it
can be done. I think it should go to Info RFC too.
That being said 6-to-4 is very close and ready for production wide IPv6
deployment and my recommendation to the public. It is the only
transition mechanism in this condition mostly because it has been widely
implemented.
It appears ISATAP is close to being the same from what I can tell of
implementations. But, I am still not clear because it is not as clear
and straight forward as 6-to-4 for network operators. It requires more
bake-off time.
No comment on Teredo or DSTM at this point but both have initial
implementations and some deployment in some geographies.
/jim
> -----Original Message-----
> From: Brian E Carpenter [mailto:brian@hursley.ibm.com]
> Sent: Sunday, May 04, 2003 4:26 AM
> To: IPv6 Operations
> Subject: Re: I-D ACTION:draft-savola-v6ops-6to4-security-02.txt
>
>
> I'm wondering what we should do with this draft.
>
> It seems to me to be basically correct (i.e. it says that
> there are specific spoofing and DoS attacks using 6to4 that
> are harder to trace than "standard" spoofing and DoS attacks).
>
> It is more explicit about the checks to be applied than the
> base 6to4 specification, but those checks cannot eliminate
> the attacks.
>
> The document might also assist intrusion-detection
> implementors in detecting these attacks.
>
> So I think it should probably be published as an Info RFC,
> and if/when we revise the basic 6to4 spec, Pekka's document
> would be a source for improving the security section.
>
> Brian
>
>
>