D-Link Forums
The Graveyard - Products No Longer Supported => Routers / COVR => DIR-636L => Topic started by: network1027 on August 17, 2013, 08:04:15 AM
-
Model : DLink DIR 626L Hardware:A1 Firmware:1.03
Hi :)
I publish a blog over IPv6 networking, extensively using and testing a couple of DIR 626L, during 30+ posts.
There seem to be a big firewall bug:
at least these 3 cases breack the IPv6 TCP stack and render the Router IPv6-useless for deny rules :
case 1: Deny all incoming connections
case 2 : Deny incoming TCP port 1
case 3 : Deny incoming TCP port 65535
the consequence : The statefull TCP goes down, no more incomming or outgoing TCP traffic. It hapens wether IPv6 simple security is Enabled or Disabled.
I've rechecked several times. can some other people confirm the problem ? I'd like very much not to make this otherwisely good product an unfair review ...
I wonder if other models are affected ( 636L, ... )
( I also found 3 other quirks :
1. The log doesn't log IPv6 dropped packets, even using a syslog server.
2. Ingress filtering doesn't work with 2 routers linked-up, so IPv6 simple security ( which ticks ingress filtering ) has to be quited to create a statefull 'allow out' rule on the exterior router. ). This is quite to be expected, since the ingress filter only performs prefix-match, not RFC-compliant RPF, but worth noting.
3. Using the :: ( collumn collumn ) sign in firewall rules for ' any IP ' works OK. When saved, however, the :: symbols get replaced by a blank space. Still everything works OK. But if you add or edit another rule, you have to remember refilling all your ' once :: now blank spaces ' in the rules with :: before saving, or you'll get a ' not a valid IP address ' message. Not easy to guess at the beginning ... :D
the first of my serie of 4 articles fully describing IPv6 Firewalls / DIR-626L for those interested in the DIR-626L IPv6 Firewall functionning :
http://computer-outlines.over-blog.com/article-ipv6-security-1-firewall-testing-methodology-119450608.html (http://computer-outlines.over-blog.com/article-ipv6-security-1-firewall-testing-methodology-119450608.html)
Thanks for any help :)
-
Welcome! (http://forums.dlink.com/index.php?topic=41537.0)
- What Hardware version is your router? Look at sticker under router.
- Link>What Firmware (http://forums.dlink.com/index.php?topic=47512.0) version is currently loaded? Found on the routers web page under status.
- What region are you located?
Internet Service Provider and Modem Configurations
- What ISP Service do you have? Cable or DSL?
- What ISP Modem Mfr. and model # do you have?
What browser are you using?
Try Opera or FF? If IE 8 or 9, set compatibility mode and test again.
Try turning off these features in Chrome:
Top right corner, little bars for options > Settings > Settings (on left) > Show advanced settings.
Uncheck these:
Use a web service to help resolve navigation errors
Use a prediction service to help complete searches and URLs typed in the address bar
Predict network actions to improve page load performance
Enable phishing and malware protection
-
Hi network1027,
There seem to be a big firewall bug:
at least these 3 cases breack the IPv6 TCP stack and render the Router IPv6-useless for deny rules :
case 1: Deny all incoming connections
case 2 : Deny incoming TCP port 1
case 3 : Deny incoming TCP port 65535
the consequence : The statefull TCP goes down, no more incomming or outgoing TCP traffic. It hapens wether IPv6 simple security is Enabled or Disabled.
Can you post a screenshot of your IPv6 firewall settings, that caused these observed problems?
What do you mean by saying "The stateful TCP goes down"? Do you mean that the existence of at least one of the three deny rules mentioned above (meaning you have switched on the firewall and selected "Turn IPv6 Filtering ON and DENY rules listed" followed by at least one rule according to your cases 1-3?) causes the IPv6 firewall to fail filterung TCP protocol and block any TCP traffic inside-->outside and outside-->inside? And what about other traffic (UDP, ICMPv6, ...)? Does the IPv6 firewall still work as expected according to your rules for these other protocols?
You said: "It hapens wether IPv6 simple security is Enabled or Disabled".
I'm not quite sure what D-Link's interpretation and implementation of "Simple Security" is. I understand this in terms of RFC6092 (https://tools.ietf.org/html/rfc6092), which is meant for most people who don't have the skills to configure a firewall: If activated it should allow any traffic initiated from inside to outside (and the return traffic requested, because the firewall is stateful) and block any unsolicited traffic coming from outside. Hence, in my opinion, you should either enable "Simple Security", and leave the firewall/filtering off or disable "Simple Security" and turn the firewall/filtering on but never enable both. If D-Link's configuration web surface allows you to enable both in my opinion this is a mistake and IPv6 firewall behaviour might be undefined.
Ingress filtering doesn't work with 2 routers linked-up, so IPv6 simple security ( which ticks ingress filtering ) has to be quited to create a statefull 'allow out' rule on the exterior router. ). This is quite to be expected, since the ingress filter only performs prefix-match, not RFC-compliant RPF, but worth noting.
I really don't understand what you want to say here. Is "Ingress filtering" a feature of your DIR-626L being implicitly activated when enabling "Simple Security"? Please post a screenshot of the settings as already asked for above. What is your Uplink-scenario? Sounds like your DIR-626L does not connect to an IPv6-ISP using a modem but is behind two uplink routers that connect to two different IPv6 ISPs providing two IPv6 prefixes, hence you are multihomed? If true, this would be an enterprise scenario. What do you expect from a home router for consumers like your DIR-626L in such an environment? Please provide some more insight into your network setup.
PacketTracer
-
Hi PacketTracer, thanks for your answer. :) here are some precisions :
1.
here are some pictures of bug-triggering configurations :
(http://a403.idata.over-blog.com/2/45/56/50/Fo1/Case1.gif)
(http://a400.idata.over-blog.com/2/45/56/50/Fo1/Case2.gif)
(http://a395.idata.over-blog.com/2/45/56/50/Fo1/Case3.gif)
As I stated, it doesn't matter if IPv6 Simple Security is ON or OFF for this bug to happen.
Symptom : The Statefull TCP Firewall goes down : IPv6 UDP and ICMPv6 are unnafected, and keep behaving within the rules, but all IPv6 TCP packets, either incomming or outgoing are dropped. ( actually, carefull wiresharking shows that TCP packets do travel Lan > Wan, but don't get their statefull ' permission to get back in '. TCP packets that travel Wan > Lan are all dropped. ).
Said more simply : make a rule that deny TCP port 65535 in, and you loose all IPv6 Internet Connectivity.
You can try it with IPv6 Simple Security unchecked, it happens the same.
2. About IPv6 Simple Security, I do agree with you. It's definitively RFC 6092 ( plus RFC 4890 ) : It's a Statefull Firewall, with allow all out and deny all in + some inboud ICMPv6 allow rules ( cf RFC 4890 ).
I really wanted to check the 626L implementation of IPv6 Simple Security, and the interractions with the firewall modes, so I did some intensive testings. The results :
. IPv6 Simple Security blocks incomming Wan, wether the firewall mode is OFF, ALLOW, or DENY.
. Using the ALLOW mode + IPv6 Simple Security blocks all outbound traffic, so you have to create an outboud ' allow out ' rule. The only point of this config ( compared to disabling IPv6 Simple Security ) is that you keep the benefits of RFC 4890 ( ICMPv6 recommended config )
. Using the DENY mode + IPv6 Simple Security allow you to create some additional deny rules while keeping the benefits of IPv6 Simple Security. This is a kind of a 'tighten up mode'. I think it can be usefull.
3. By link up, I mean ' cascading ', ' chaining up', in-line .. :
http://a405.idata.over-blog.com/2/45/56/50/IPSN8/Static8a.gif (http://a405.idata.over-blog.com/2/45/56/50/IPSN8/Static8a.gif)
I don't know what is the english correct expression ?!
Ingress Filtering in this case is an option in the firewall, that defeats spoofed source address packets to leave our network and enter the ISP network. ( RFC 2827 / RFC 3704 ) :
http://a51.idata.over-blog.com/2/45/56/50/SEC/S2/S2c.gif (http://a51.idata.over-blog.com/2/45/56/50/SEC/S2/S2c.gif)
the problem is the implementation : as the 626L is a consummer product, it just compares for each outgoing packet the source IP to the Lan interface subnet. In case of mismatch, the packet is dropped.
If you link up two routers, packets from the innermost subnet are dropped by the outter router.
The only solution : to create an 'allow out ' rule on the outtermost Router to override the ingress filter.
Beside, IPv6 Simple Security automatically turns on Ingress Filter, which is logical.
It is a change, compared to IPv4 easy Router Cascading Firewall-wise.
I know this is too far off picky, for a 40$/€ router. I'm just trying to push it to its limits, for the goal of learning :)
-
Hi network1027,
thank you for providing more details so the things you talk about can be better understood.
First of all I am astonished that "Simple Security" and the two "Firewall ON" modes can be combined -- <ironic>and how nice that D-LINK explains the correlation of them that elaborately</ironic>.
So thank you again that you brought some expert insight to the topic by explaining the details:
2. About IPv6 Simple Security, I do agree with you. It's definitively RFC 6092 ( plus RFC 4890 ) : It's a Statefull Firewall, with allow all out and deny all in + some inbound ICMPv6 allow rules ( cf RFC 4890 ).
I really wanted to check the 626L implementation of IPv6 Simple Security, and the interractions with the firewall modes, so I did some intensive testings. The results :
. IPv6 Simple Security blocks incoming Wan, wether the firewall mode is OFF, ALLOW, or DENY.
. Using the ALLOW mode + IPv6 Simple Security blocks all outbound traffic, so you have to create an outbound ' allow out ' rule. The only point of this config ( compared to disabling IPv6 Simple Security ) is that you keep the benefits of RFC 4890 ( ICMPv6 recommended config )
. Using the DENY mode + IPv6 Simple Security allow you to create some additional deny rules while keeping the benefits of IPv6 Simple Security. This is a kind of a 'tighten up mode'. I think it can be usefull.
According to your results, when combined with enabled "Simple Security" I would draw the following conclusions:
- In firewall mode DENY, in general rules for direction WAN-->LAN are useless because in this direction all unsolicited traffic (except ICMPv6 traffic allowed due to RFC4890 (https://datatracker.ietf.org/doc/rfc4890/)) is blocked anyway by enabled "Simple Security" (as you said: "IPv6 Simple Security blocks incoming Wan, wether the firewall mode is OFF, ALLOW, or DENY"). Hence any rule should only be defined for direction LAN-->WAN and is then useful to disallow some specific traffic going out unrestricted otherwise. A rule for WAN-->LAN would only be useful for denying some ICMPv6 types that are allowed via enabled "Simple Security" according to RFC4890 (https://datatracker.ietf.org/doc/rfc4890/).
- The firewall mode ALLOW works almost the same as in case when "Simple Security" is switched off except that ICMPv6 rules according to RFC4890 (https://datatracker.ietf.org/doc/rfc4890/) are in place when combined with enabled "Simple Security".
Do you agree to my conclusions?
But on the other hand you also say in the "Ingress Filtering" section:
The ' Firewall On and Allow listed ' does disable IPv6 Simple Security.
I'm a bit confused now because this seems to contradict your former statement "Using the ALLOW mode + IPv6 Simple Security ...". So what is true now?
Unfortunately I can neither confirm nor disprove your results and error situations because I don't have this D-Link device available. But you are not the only one fighting with D-Link's firewall implementation, see for example this thread (http://forums.dlink.com/index.php?topic=55088.0), describing other firewall implementation bugs with DIR-868L.
Ingress Filtering in this case is an option in the firewall, that defeats spoofed source address packets to leave our network and enter the ISP network. ( RFC 2827 / RFC 3704 ) :
Okay, for me "Ingress" means traffic coming in to a router interface which could be either WAN or LAN. You only considered traffic coming in to LAN interface, while I only had thought of traffic entering the WAN interface and using ingress filtering to drop packets with source addresses belonging to my LAN ...
So if I understand you right your demand for ingress filtering on the LAN interface is to implement RPF. So nothing left to comment on this except my estimation that D-Link won't do this for this 40 € device.
PacketTracer
-
Thanks for your comments Packet Tracer. By the way, I did add a third quirk in the topic :D
Hi network1027,
thank you for providing more details so the things you talk about can be better understood.
First of all I am astonished that "Simple Security" and the two "Firewall ON" modes can be combined -- <ironic>and how nice that D-LINK explains the correlation of them that elaborately</ironic>.
Yes, I got very puzzled when I first used their IPv6 firewall, and very much more puzzled when I looked at the DLink Manual ..... Ticking the ' Enable IPv6 Simple Security ' enables the IPv6 Simple Security mode :D who would have guessed ?
According to your results, when combined with enabled "Simple Security" I would draw the following conclusions:
- In firewall mode DENY, in general rules for direction WAN-->LAN are useless because in this direction all unsolicited traffic (except ICMPv6 traffic allowed due to RFC4890 (https://datatracker.ietf.org/doc/rfc4890/)) is blocked anyway by enabled "Simple Security" (as you said: "IPv6 Simple Security blocks incoming Wan, wether the firewall mode is OFF, ALLOW, or DENY"). Hence any rule should only be defined for direction LAN-->WAN and is then useful to disallow some specific traffic going out unrestricted otherwise. A rule for WAN-->LAN would only be useful for denying some ICMPv6 types that are allowed via enabled "Simple Security" according to RFC4890 (https://datatracker.ietf.org/doc/rfc4890/).
- The firewall mode ALLOW works almost the same as in case when "Simple Security" is switched off except that ICMPv6 rules according to RFC4890 (https://datatracker.ietf.org/doc/rfc4890/) are in place when combined with enabled "Simple Security".
Do you agree to my conclusions?
Yes, you got it perfectly right, I 100% agree :)
But on the other hand you also say in the "Ingress Filtering" section:
I'm a bit confused now because this seems to contradict your former statement "Using the ALLOW mode + IPv6 Simple Security ...". So what is true now?
My mistake. I edited the sentence. What I meant was ' Using the Allow mode + IPv6 Simple Security defeats THE GOAL AND SPIRIT of IPv6 Simple Security, which is to be simple and intuitive. The DENY mode has an additive effect over IPv6 Simple Security, you just add some restrictions, it's intuitive. The ALLOW mode has a more radical effect, as it cancels the default LAN>WAN permission. Just my feeling. You perfectly summed up ma tests in your first quote, and got the same conclusions as me.
Okay, for me "Ingress" means traffic coming in to a router interface which could be either WAN or LAN. You only considered traffic coming in to LAN interface, while I only had thought of traffic entering the WAN interface and using ingress filtering to drop packets with source addresses belonging to my LAN ...
So if I understand you right your demand for ingress filtering on the LAN interface is to implement RPF. So nothing left to comment on this except my estimation that D-Link won't do this for this 40 € device.
PacketTracer
Yes, the Ingress Filtering got me puzzled at first. As they don't do Wan>Lan filter to drop Lan-prefix-spoofed addresses from entering by the Wan side .... and only do Lan>Wan filter, I would call it an Egress Filter . Or maybe they meant : its the ' Ingress Filter of your ISP ' :D
Yes, they won't do Reverse Path Forwarding here. Anyway, I guess that people that line-up 2 Routers are skilled enough to take care of firewall rules. So that's more a quirk than a bug for me.
I wonder, how many models share a common firmware ( beside NIC drivers changes ). I guess they don't maintain a distinct network engine software for each model. I'd very like to have a clue on this :)
Anyway, thanks for your comments and opinions. Good to have a second look over a test serie :D
-
Hi network1027,
to summarize:
- In order to understand how D-Link's IPv6 firewall implementation works and how several configuration items work together some reverse engineering is needed by placing the D-Link box into a suitable lab environment, performing adequate test scenarios and analyzing what happens on the wire. Thanks to your pioneering work whose results I believe to have understood, besides D-Link's IPv6 firewall implementing software engineers now 2 additional inhabitants of planet earth not employed at D-Link believe to have understood D-Link's sophisticated IPv6 firewall implementation 'philosophy' ;D.
- You showed that 'ingress filtering' does not protect the customer but in effect is an egress filter that protects the ISP. Though this is not what I expect from a customer's point of view it is at least friendly to the ISP :D.
- As a side effect of your research you found some error conditions that cause the IPv6 firewall state machine for TCP to fail. Of course this should be reported to D-Link. @FurryNutz: Your job?
PacketTracer
-
Thank you to the both of you for all of your hard work, troubleshooting, results and information.
I will forward this onto D-Link and hope that someone will and can provide some information on all of this.
Please be patient.
Thank you.
Furry.
-
Just out of precision :
I didn't test and reshearch IPv6 Simple Security compliance to RFC 4890. I just observed that :
. when using IPv6 Simple Security, some ICMPv6 commands ( Ping and Tracert ) seem to be granted an invisible 'allow in rule', even while using the restrictive Firewall ON+Allow Rules listed mode.
. when disabling IPv6 Simple Security, Ping and Tracert commands behave in a logical way ( Allow mode + no allow rule for ICMPv6 = no incomming pings or tracerts, Deny mode + no deny rule for ICMPv6 = incomming pings and tracerts working, etc ... )
I didn't test how much of RFC 4890 is implemented .. :)
-
... might also be difficult to test if a firewall is RFC4890-compliant if you don't know how the firewall works at all, for example:
- You send out a Ping (ICMPv6 Echo Request) and get a Ping reply (ICMPv6 Echo Reply). Is this because the firewall has a state machine for ICMPv6 and allows it as a stateful reply or is it because in fact it has no ICMPv6 state machine but allows the reply due to an implicit rule active due to RFC4890?
- You initiate an outgoing TCP connection (which in turn establishes a state for this flow in the firewall) and you receive am IPCMv6 error message (e.g. "packet too big") referencing an IPv6 packet belonging to this TCP connection. Is this because the firewall evaluates the ICMPv6 error message as belonging to the established flow (and hence allows it) or is it once more due to an implicit rule active due to RFC4890?
-
... might also be difficult to test if a firewall is RFC4890-compliant if you don't know how the firewall works at all, for example:
- You send out a Ping (ICMPv6 Echo Request) and get a Ping reply (ICMPv6 Echo Reply). Is this because the firewall has a state machine for ICMPv6 and allows it as a stateful reply or is it because in fact it has no ICMPv6 state machine but allows the reply due to an implicit rule active due to RFC4890?
- You initiate an outgoing TCP connection (which in turn establishes a state for this flow in the firewall) and you receive am IPCMv6 error message (e.g. "packet too big") referencing an IPv6 packet belonging to this TCP connection. Is this because the firewall evaluates the ICMPv6 error message as belonging to the established flow (and hence allows it) or is it once more due to an implicit rule active due to RFC4890?
Generally speaking about IPv6 Routers, I understand your point and think you're right.
What is funny is that in the case of the DLink DIR626L, as we can disable IPv6 Simple Security, it's easy to compare the behavior changes between IPv6 Simple Security ON and OFF. Then, assuming the behavior change is due to RFC4890 being toggled ON/OFF, to draw conclusions on the RFC4890 implementation.
Am I right here ? I'm setting the experiment about this right now :D
DLink will have me better my skills about these 2 RFC 6092 and RFC 4890 :D
-
What is funny is that in the case of the DLink DIR626L, as we can disable IPv6 Simple Security, it's easy to compare the behavior changes between IPv6 Simple Security ON and OFF. Then, assuming the behavior change is due to RFC4890 being toggled ON/OFF, to draw conclusions on the RFC4890 implementation.
Am I right here ? I'm setting the experiment about this right now :D
You assume that RFC4890 behaviour is completely bound to Simple Security but so far you have only proved that 'ICMPv6 echo requests' (Ping or Traceroute) are allowed to pass the firewall ('Transit Traffic' according to RFC4890) from WAN to LAN when Simple Security is active, even if there is no explicit allow rule in 'Firewall ON+Allow Rules listed' mode.
On the other hand taking the statements of Chapter 4.3.1 (http://tools.ietf.org/html/rfc4890#section-4.3.1) (Traffic That Must Not Be Dropped) and Chapter 4.3.2 (http://tools.ietf.org/html/rfc4890#section-4.3.2) (Traffic That Normally Should Not Be Dropped) of RFC4890 together (and neglecting mobility support) you get the result that ICMPv6 error messages of types 1-4 (1: Destination Unreachable, 2: Packet Too Big, 3: Time Exceeded, 4: Parameter Problem) and any codes must or at least should be allowed, because these ICMPv6 error messages are essential to the establishment and maintenance of communications.
Hence if according to your assumption RFC4890 behaviour is completely bound to active Simple Security you would end up in a situation where a host on the LAN side of the firewall could fail to establish or maintain an outgoing communication, namely if you disable Simple Security, switch 'Firewall ON and Allow Rules listed' mode and define for example one rule allowing any outgoing traffic. In this case you should have to also define additional rules that allow the above mentioned ICMPv6 error types to pass the firewall WAN --> LAN or in other words: you should have to explicitly define a rule set according to RFC4890 (because it is not implicitly available due to disabled Simple Security). Does the firewall configuration surface of DIR-626L allow to define rules for ICMPv6 protocol and ICMPv6 message types? I don't think so. And hence (because the configuration surface does not allow to define RFC4890-compliant ICMPv6 rules explicitly) a disabled Simple Security would be senseless in this situation.
So I assume that in my example constellation the ICMPv6 error messages (and incoming ICMPv6 echo replies to outgoing ICMPv6 echo requests but no incoming ICMPv6 echo requests) can pass the firewall WAN --> LAN (even if due to a disabled Simple Security there are no corresponding ICMPv6 allowing rules available) because the TCP, UDP and ICMPv6 state machines evaluate those ICMPv6 messages as belonging to an established flow. Switching on Simple Security in this situation just would additionally allow incoming ICMPv6 echo requests to pass.
I think it is a bit hard to test all this because you have to produce outgoing traffic that provokes ICMPv6 error messages of the types discussed above. But one simple case could be to reduce the current hop limit of a Windows PC (netsh int ipv6 set int <Interface name> currenthoplimit=<value>) to some small <value> and then initiate a TCP connection or a UDP request to a destination that is more than <value> hop counts away. This should provoke an ICMPv6 Time Exceeded message returned by some intermediate router in the path to the destination. Ok, even simpler: you could just try to establish outgoing connections to remote TCP or UDP ports where no service is listening to incoming requests - this should eventually provoke an ICMPv6 destination unreachable error message returned from the destination host. Or try to reach servers out of range 2000::/3 which should also provoke an ICMPv6 destination unreachable error message send back by some Internet IPv6 router.
<EDIT>:
Some facts from RFC6092 (http://tools.ietf.org/html/rfc6092):
- Recommendations for filtering ICMPv6 messages in firewall devices are described separately in [RFC4890] and apply to residential gateways,...
--> Hence RFC4890 is an integral part of RFC6092 - REC-5: Outbound packets MUST NOT be forwarded if the source address in their outer IPv6 header does not have a unicast prefix configured for use by globally reachable nodes on the interior network.
--> This covers ingress filtering on the LAN interface - REC-6: Inbound packets MUST NOT be forwarded if the source address in their outer IPv6 header has a global unicast prefix assigned for use by globally reachable nodes on the interior network.
--> This covers ingress filtering on the WAN interface - REC-10: IPv6 gateways SHOULD NOT forward ICMPv6 "Destination Unreachable" and "Packet Too Big" messages containing IP headers that do not match generic upper-layer transport state records.
--> This restricts RFC4890 in so far that "Dest. Unreachable" and "Packet Too Big" must additionally match some flow state to get passed. This would mean otherwise that other ICMPv6 packet types could pass in any case according to RFC4890 even if they don't match any existing flow state - REC-18: If gateway forwards a UDP flow, it MUST also forward ICMPv6 "Destination Unreachable" and "Packet Too Big" messages containing UDP headers that match the flow state record.
--> This is the UDP case of the general case as specified by REC-10. - REC-36: If gateway forwards a TCP flow, it MUST also forward ICMPv6 "Destination Unreachable" and "Packet Too Big" messages containing TCP headers that match the flow state record.
--> This is the TCP case of the general case as specified by REC-10.
</EDIT>
Interested in further results ...
-
You assume that RFC4890 behaviour is completely bound to .......
</EDIT>
Interested in further results ...
I've been thinking about your remarks and ideas, and setup a Firewal Analysis protocol to this : http://computer-outlines.over-blog.com/article-ipv6-security-6-ipv6-firewall-analysis-119871380.html (http://computer-outlines.over-blog.com/article-ipv6-security-6-ipv6-firewall-analysis-119871380.html)
The idea is to use genuine traffic( using a ttl=2, .. ), replay traffic ( which dodges the statefull action ) and crafted traffic ( to tests reply messages that are not easy to trigger ).
Do you think this protocol is OK ?
the conclusions are :
The DLink IPv6 firewall is completely statefull, allowing back previous outbound requests ( even an ICMPv6 reply to an outbound TCP querry )
So not using IPv6 Simple Security works ok, as the IPv6 Statefull Firewall allow back in related ICMPv6 messages
IPv6 Simple Security do add an invisible inboud allow rule for these three ICMPv6 error messages :
Echo reply
Time Exceeded
Parameter problem
as well as an invisible outbound allow rule for the Echo Request that overrides the allow mode restrictive behaviour ( ie when allow mode drops outbound traffic unless explicitely allowed, Ipv6 Simple Security gives Echo Request an exception )
Using an ICMPv6 deny rule works 100%, and overrides any rule.
This is ok with your EDIT part ( IPv6 gateways SHOULD NOT forward ICMPv6 "Destination Unreachable" and "Packet Too Big" messages containing IP headers that do not match generic upper-layer transport state records. )
So I'd say DLink IPv6 Simple Security really implements RFC6092. but not RFC4890 ( not all four types 1-4 error messages are allowed in ).
What do you think ? :)
-
Do you think this protocol is OK ?
From your blog: To trigger ICMPv6 Time Exceeded (hop limit exceeded), we'll have PC1 to ping OS Router with a too short TTL: ping -i 2 [ OS Router IPv6 Lan Address ]
In my opinion it should say: To trigger ICMPv6 Time Exceeded (hop limit exceeded), we'll have PC1 to ping Router 2 with a too short TTL: ping -i 2 [ Router 2 IPv6 Lan Address ]
... what provokes OS Router to send back the desired Time Exceeded message (when it reduces Hop Count to 0 before trying to forward the ping to Router 2)
From your blog: The currenthoplimit command in Windows seems volatile ( 5s ). A script is needed in Windows OS to perform the command in a 2s loop. ...
This is probably due to a "Cur hop limit" value <> 0 sent by router advertisements from router 1 (wireshark filter "icmpv6.type=134") every few minutes (average about every 10 minutes) which overrides your manual interface value changes. To prevent this, set "netsh int ipv6 set int <interfacename> routerdiscovery=disabled" and configure all interface parameters (including IPv6 address, Gateway, ...) manually.
While your protocol does not cover "Packet Too Big" and "Parameter Problem" error messages (test if they are allowed because they belong to an established packet flow), its basic ideas are good enough to cover the other cases discussed here (brilliant: your record and replay scenario).
IPv6 Simple Security do add an invisible inbound allow rule for these three ICMPv6 error messages :
Echo reply
Time Exceeded
Parameter problem
as well as an invisible outbound allow rule for the Echo Request that overrides the allow mode restrictive behaviour ( ie when allow mode drops outbound traffic unless explicitly allowed, Ipv6 Simple Security gives Echo Request an exception )
"Echo reply" is not an "ICMPv6 error message". But apart from that: What happens, if I disable Simple Security, enable firewall in allow mode and define a rule allowing any outgoing traffic: Do I get an ICMPv6 echo reply to an outgoing ICMPv6 echo request? If yes, this would mean there is an ICMPv6 state machine and I don't have to switch on Simple Security to allow incoming ICMPv6 echo replies. Furthermore this would mean that enabled Simple Security just establishes the invisible outbound rule for ICMPv6 echo requests and any corresponding ICMPv6 echo reply is allowed because it belongs to the ICMPv6 flow established by the outgoing request but not because there is an incoming ICMPv6 echo reply rule due to enabled Simple Security.
So I'd say DLink IPv6 Simple Security really implements RFC6092. but not RFC4890 ( not all four types 1-4 error messages are allowed in ).
What do you think ?
Hm... According to your results I wouldn't agree: When Simple Security is enabled then IMCPv6 echo requests and their stateful replies are allowed to pass in both directions (right?). Furthermore incoming ICMPv6 error messages "Destination Unreachable" (proved by you) and "Packet Too Big" (not yet proved) are allowed if they belong to an established flow. So far this fulfills RFC6092 completely but RFC4890 only partially. And you stated that with active Simple Security incoming ICMPv6 error messages "Time Exceeded" (proved by you) and "Parameter Problem" (not yet proved) are allowed even if they don't belong to established flows. This corresponds exactly to what I said in my EDIT section (comment to REC10): "--> This restricts RFC4890 in so far that "Dest. Unreachable" and "Packet Too Big" must additionally match some flow state to get passed. This would mean otherwise that other ICMPv6 packet types could pass in any case according to RFC4890 even if they don't match any existing flow state". All facts taken together shows that RFC4890 is fulfilled either (at least in so far as discussed here, other ICMPv6 message types and non-transit traffic (such as all that Neighbor Discovery stuff) have yet to be analyzed).
-
Hi Packettracer :D
Yes, the TTL ping should be directed to Router 2. Anyway, pinging the OS Router did trigger the ICMPv6 message, so I kept with this. I'll correct my post.
You're right, I left the router discovery enabled on the interface, so the volatile currenthoplimit. I correct my post.
I have troubles managing the Packet too big and parameter problems. The problem is that they need to pass Router1, but to get bounced back by OS router. I set a low MTU on OS Router, but it didn't generate a packet too big message, it started fragmenting. ( By the way, isn't packet fragmentation prohibited in IPv6 ? Thus the reason for the packet too big message ? )
As for Parameter problem, I didn't manage to trigger one yet. I'll give it another try.
So I went for packet crafting instead of raw packet replay, for the messages I have a hard time to trigger/contol. But it's les reliable for analysis, because they can be mis crafted.
For the 7 other types ( RA, RS, NA, NS, ...) they seem to be blocked inbound using IPv6 Simple Security. But I have to check more carefully.
What happens, if I disable Simple Security, enable firewall in allow mode and define a rule allowing any outgoing traffic: Do I get an ICMPv6 echo reply to an outgoing ICMPv6 echo request? If yes, this would mean there is an ICMPv6 state machine and I don't have to switch on Simple Security to allow incoming ICMPv6 echo replies. Furthermore this would mean that enabled Simple Security just establishes the invisible outbound rule for ICMPv6 echo requests and any corresponding ICMPv6 echo reply is allowed because it belongs to the ICMPv6 flow established by the outgoing request but not because there is an incoming ICMPv6 echo reply rule due to enabled Simple Security.
yes, you get an ICMPv6 echo reply. better : turn simple security off / allow mode / Allow TCP 80 out.
Then, set a currenthoplimit=2
You'll get an ICMPv6 Time exceeded message back in.
There is a complete IPv6 state machine : ICMPv6 state machine
(outbound-non-ICMPv6) traffic-related ICMPv6 authorisations.
Disabling IPv6 Simple Security triggers a very square and straightforward functioning :
everything behaves according to the rules, no invisible premissions, ...
So far, IPv6 Simple Security add this :
Invisible inbound rule for :
Echo reply
Time Exceeded
Parameter problem
Invisible outbound rule THAT OVERRIDES THE ALLOW MODE RESTRICTIVE EFFECT ( ISS + Allow mode is restrictive ) for :
Echo request ( and thus because of state, echo reply is allowed in )
nb : Using an ICMPv6 deny rule works 100%, and overrides any rule
nb2 : I need to recheck the ping request/ping reply for each way ( Lan)Wan / Wan/Lan )
nb3 : I'll check soon some other traffic ( IPSec, Mobile prefix messages ), as well as give a special attention to :
Router Renumbering ( 138 )
Node Information ( Query and Reply )
These two should be allowed within a site
nb4 : I need to re-read these two RFCs :D
Thanks for your help and ideas :) I wish very much to better my IPv6 skills :)
-
Hi network1027,
I have troubles managing the Packet too big and parameter problems. The problem is that they need to pass Router1, but to get bounced back by OS router. I set a low MTU on OS Router, but it didn't generate a packet too big message, it started fragmenting. ( By the way, isn't packet fragmentation prohibited in IPv6 ? Thus the reason for the packet too big message ? )
Yes, an IPv6 router must not fragment forwarded IPv6 packets (but of course it may fragment IPv6 packets originated by itself). Only a host as a source of an IPv6 packet is allowed to fragment it. Are you sure OS Router (W2K8 R2?) really fragmented a packet originated by PC1?
I would agree to your approach to reduce the MTU on OS router's link to Router2 below 1500 (given all downstream links have an Ethernet MTU of 1500) to provoke a Packet Too Big ICMPv6 message sent by OS router. But be careful: MTU is also advertised by RA which might override manually changed interface MTU values (Router2 RAs announcing MTU=1500 might override a manually changed MTU value on OS router's link to Router2).
As a workaround you could configure Router2 to operate 6to4, tunneling IPv6 packets through the IPv4 Internet towards some 6to4 relay connecting to the IPv6 Internet. This would reduce the MTU on the link between OS router and Router2 to a value of 1480 (inspect RA sent by Router2). Hence Router2 should send Packet Too Big for any IPv6 packet greater than 1480 bytes.
<EDIT>
Correction for "This would reduce the MTU on the link between OS router and Router2 to a value of 1480 (inspect RA sent by Router2)": The MTU beyond Router2 would be reduced to MTU=1480, not the MTU for the link between OS router and Router2. But maybe (depending on Router2's configuration) Router2 also announces this reduced MTU for the LAN between OS router and Router2 (inspect RA sent by Router2), and this reduced MTU is accepted by OS router, then OS router will send an ICMPv6 "Packet Too Big" for IPv6 packets > 1480 bytes. Otherwise it is Router2 sending ICMPv6 "Packet Too Big".
</EDIT>
-
... this case of IPv6 firewall failure has been added as case [3] to a list of other cases, see here (http://forums.dlink.com/index.php?topic=58287.msg226285#msg226285).
PT