Le lundi 30 juillet 2007, Internet-Drafts@ietf.org a écrit : > Title : Teredo Security Concerns > Author(s) : J. Hoagland, S. Krishnan > Filename : draft-ietf-v6ops-teredo-security-concerns-00.txt > Pages : 21 > Date : 2007-7-30 Some comments (some probably already made): * Section 2.1 says: "When Teredo is being enabled or when it is going to be used for the first time, perhaps there should be a descriptive warning about the possible evasion that will occur." That feels really intractable in practice. I understand it's a "should perhaps", but I doubt anyone's ever going to implement this, really. * Section 2.2: not at all clear to me what the recommendations mean to Teredo clients. The protocol already includes quite a bunch of sanity checks on IPv6 addresses. If anything, what should additionaly be done needs to be clarified. * Section 2.3 on source routing should be slimmed down; the Recommendations should consist of following draft-ietf-ipv6-deprecate-rh0, which need to be Reference'd. * Sections 4.1, 4.2, 4.3: In theory, bringing up the service only when needed is a good idea. This is however a bit vague. The only way I can think of doing this without wreaking havoc to the normative non-blocking-ness of getaddrinfo() from the Basic IPv6 API, is to bring the Teredo tunnel whenever there is no other global IPv6 connectivity. That however is a very objectable idea, as it effectively suppress the idea of "host-specific" relays. As such, the real "global" Teredo relays would be used even when they could be avoided, which is bad considering they are a bottleneck already. Whether this means that or something else, I think it would need clarifications. * Section 5.1: Flag randomization is a protocol update. I personnaly do not care whether the working group is chartered for it, or not. It still is a protocol update. I suppose, the draft needs to target Standard Tracks and tentatively Update RFC4380 for this to stand. I cannot say I think burning out all but one of the reserved flags was a terrible idea, but, oh well, it's done by the de facto monopoly client implementation. * Section 5.2: exact same remark. Deprecating the Cone bit is a protocol update. Besides, this has implications to the qualification procedure, so it cannot be that simple. (I agree it should be done however). Best regards, -- Rémi Denis-Courmont http://www.remlab.net/
Attachment:
signature.asc
Description: This is a digitally signed message part.