Hi, I've read quickly these two drafts. Here are some comments/questions:
o draft-gont-v6ops-ra-guard-evasion IMHO, this draft should update RFC 6105 (If so, RFC6105 reference should move from Informative References section to the Normative References one). Just a comment about your example for the fragmentation case with 2 Destination extensions: from RFC2460 (section 4.1), this only occurs when there is also a Routing Header extension, so I have to add a RH in your example (better chance to get a fragmentation :)) o draft-gont-6man-nd-extension-headers IMHO, this is not a good idea to forbid the use of IPv6 extension with NDP messages, especially when the reason is partially based on implementation issues (i.e. the implementation is not able to process an IPv6 packet): today, there is no real use of Extension header with NDP but, tomorrow, if we need such an use for a solution, what will happen? Regarding the fragmentation, is it not possible for the RA-Guard device to reassemble the fragments and so to be able to check whether this a RA message or not? Thanks in advance for your reply. Best regards. JMC. 2011/6/10 Fernando Gont <ferna...@gont.com.ar>: > Hi, > > Some folks have expressed (both on-list and off-list) that they would > prefer a less agressive solution for the RA-Guard evasion vulnerability. > So I'd like to hear comments about the possible alternatives.. > > The current I-Ds (draft-gont-6man-nd-extension-headers and > draft-gont-v6ops-ra-guard-evasion) basically take this approach: > > * Prohibit use of extension headers in ND messages. A host > implementation must not produce these packets, and must discard them if > it receives them > * This results in a RA-Guard implementation that is as simple as > possible (it only has to look at the header following the fixed IPv6 > header). > > > A more relaxed approach would be as follows: > * Extension headers are allowed with ND messages. > * If the packet is fragmented, the upper-layer header (ICMPv6 in this > case) must be present in the first fragment (i.e., hosts must not > generate packets that violate this requirement, and must discard them if > they receive them). > * Possibly have the RA-Guard box enforce a limit on the maximum number > of extension headers that it will process (e.g., if after jumping to > the, say 10th header the upper-layer header is not found, drop the packet) > * This approach is less aggressive than the one proposed in the > aforementioned I-Ds (i.e., more flexibility), but of course would also > mean that the RA-Guard implementation would need to follow the header > chain, thus leading to increased complexity, and possible performance > issues. > > Any comments/thoughts will be very much appreciated. > > Thanks! > > Best regards, > -- > Fernando Gont > e-mail: ferna...@gont.com.ar || fg...@acm.org > PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 > > > > _______________________________________________ > v6ops mailing list > v6...@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
