Red Hat Bugzilla – Bug 446250
IPV6DOD: xfrm reverse icmp feature does not seem to work correctly.
Last modified: 2009-06-19 23:56:51 EDT
Joy M. Latten <firstname.lastname@example.org> - 2008-05-12 21:28 EDT
Testing the new xfrm reverse feature for icmpv6 and am not able to get it to
work as I believe it should.
I have following setup.
A ---------- B ---------- C -------- D
eth0 eth1 eth0 eth0 eth1 eth0
B and C are gateways, with eth0-eth0 tunnel.
A is behind B and D is behind C.
I remove D's interface to cause an icmp desination unreachable message.
My ip configuration below sets up a tunnel between B and C, so I expected the
icmp error message to be "reversed" and map to my tunnel SA. But this did not
happen. Instead src and dst was B(eth1) and A(eth0) respectively.
Following is my ip config. I modified ip to accept a policy flag
to set XFRM_POLICY_ICMP so that outbound knows to do xfrm_reverse for icmp.
./ip xfrm policy flush
./ip xfrm state flush
./ip xfrm state add src fc00:0:0:105::64 dst fc00:0:0:105::35 proto esp spi
0x201 mode tunnel enc "cbc(des3_ede)"
./ip xfrm state add src fc00:0:0:105::35 dst fc00:0:0:105::64 proto esp spi
0x3433 mode tunnel enc "cbc(des3_ede)"
./ip xfrm policy add dir out flag icmp src fc00:0:0:141::/64 dst
fc00:0:0:165::/64 tmpl src fc00:0:0:105::64 dst fc00:0:0:105::35 proto esp mode
./ip xfrm policy add dir in flag icmp src fc00:0:0:165::/64 dst
fc00:0:0:141::/64 tmpl src fc00:0:0:105::35 dst fc00:0:0:105::64 proto esp mode
./ip xfrm policy add dir fwd flag icmp src fc00:0:0:165::/64 dst
fc00:0:0:141::/64 tmpl src fc00:0:0:105::35 dst fc00:0:0:105::64 proto esp mode
In ipv6/icmp.c, icmpv6_send() we call xfrm_lookup first to see if an SA or SPD
entry exists. if not, xfrm6_decode_session_reverse(skb, &fl2) to reverse the
flow and then xfrm_nlookup() is called, but with fl instead of fl2. Thus we
continue to use the same flow instead of the reversed one.
After changing this such that xfrm_nlookup() gets called with fl2, the traffic
looks as I expected in that headers from icmp payload are reversed and used to
lookup SA/SPD. It finds the tunnel SA and uses this.
However, my ping6 is still not successful. It seems B receives the ESP packet,
the icmpv6_rcv appears to process everything successfully and forwards, and then
the pkt disappears.
Will continue to look at.
However, shouldn't xfrm_nlookup() be called with fl2?
Or am I misunderstanding how this works?
Contact Information = Joy Lattenemail@example.com
Machine Type = p520
Please add firstname.lastname@example.org and
email@example.com to the cc list.
------- Comment From firstname.lastname@example.org 2008-05-13 17:45 EDT-------
It looks like upstream kernel has this problem too...
Created attachment 305300 [details]
tcpdump of machine B upon receiving icmp error message.
This tcpdump is from machine B at eth0. It shows that machine B receives the
ESP packet just fine. It appears to also decrypt the ipsec packet just fine too
since I see ICMP Dest Unreachable pkt with src=C and dst=A being sent to A.
What I don't get is why do I see this pkt on eth0. Shouldn't this have been
forwarded to B's eth1 to send to A?
Perhaps this is why A never receives the packet.
Yes, this is the problem... because just for the heck of it, I did a ping from
C to A and it worked just fine. The packet was forwarded to B's eth1 to send to
But the successful ping from C to A did not require ipsec.
So, I think after the icmp error message pkt is decrypted, ipsec is not
forwarding to correct interface or something.
Yes the flow on the output side is wrong. Since you've already patched it could
you send a patch to netdev? Thanks!
As to the other problem, please make sure that the ICMP flag is set on the state
on the receive side as otherwise the packet will fail the inbound policy check
and be discarded.
------- Comment From email@example.com 2008-05-15 12:29 EDT-------
Herbert, yes, will create and send patch.
Geez! I forgot about the input flag! Will try it.
Created attachment 305608 [details]
Fix reverse flow lookup
Here is a back-port to RHEL5.
------- Comment From firstname.lastname@example.org 2008-05-16 17:04 EDT-------
The sending side works great with this fix, but I am still seeing problems on
receiving side. Even with inbound ICMP flag, XFRM_STATE_ICMP set in SA.
Because the tunnel is between 2 security gateways, B & C, the icmp error message
will get ipsec'd and sent on C. B will receive it... but he will only decrypt
the message and then it should get forwarded, right? B's icmp layer won't see
anything since he is not final destination, right? A is final destination and
A's icmp layer will process. But it will not have a secpath/SA, or anything
since A is just a box behind the SG.
It seems on B, after packet is decrypted, it is put onto eth0, instead
of being forwarded to eth1.
I am not too familiar with this area, but after looking at code,
I am wondering if in ip6_input_finish(), "resubmit" happens and gets
wrong idev or something...
------- Comment From email@example.com 2008-05-16 19:13 EDT-------
ok, forget what I said about "resubmit" since this is a tunnel mode pkt.
------- Comment From firstname.lastname@example.org 2008-05-16 20:05 EDT-------
not sure why the decrypted pkt is forwarded onto eth0 and not eth1.
routes look correct in my routing table... when I ping C to A things are
forwarded correctly then. But not after decrypting an icmp error message when
src is C and dst is A...
I see, you're trying to use it as an IPsec gateway as opposed to a host. I
thought we agreed that we were only going to support this as a host, not a
router. That's why I never implemented the forwarding part. Do we want to
support a router as well?
------- Comment From email@example.com 2008-05-19 16:19 EDT-------
Herbert, sorry, I forgot! I have been testing in tunnel mode with SGs!
In rfc 4301, Section 6.2, "The major security concern here is that a compromised
host or oruter might emit erroneous ICMP error messages that could degrade
service for other devices "behind" the security gateway, or that could even
result in violations of confidentiality."
I was thinking of this scenario when I started testing and tried to recreate it!
I am wondering... and would like your opinion, (since I am just now really
understanding all this) but would not this particular "protecting icmp error
messages" be more needed in cases where the packet will be forwarded "behind"
the gateway? If so, I guess we will eventually need it.
Sorry, it's way too late to add any new features. Besides, if we were going to
support IPsec as a gateway, then there is a lot more to be done than just ICMP.
Of course, this is something that should eventually be added to Linux, just not
You can download this test kernel from http://people.redhat.com/dzickus/el5
------- Comment From firstname.lastname@example.org 2008-06-27 00:18 EDT-------
Thanks! Closing this bug.
~~~ Attention Partners! ~~~
Please test this URGENT / HIGH priority bug at your earliest convenience to ensure it makes it into the upcoming RHEL 5.3 release. The fix should be present in the Partner Snapshot #2 (kernel*-122), available NOW at ftp://partners.redhat.com. As we are approaching the end of the RHEL 5.3 test cycle, it is critical that you report back testing results as soon as possible.
If you have VERIFIED the fix, please add PartnerVerified to the Bugzilla Keywords field to indicate this. If you find that this issue has not been properly fixed, set the bug status to ASSIGNED with a comment describing the issues you encountered.
All NEW issues encountered (not part of this bug fix) should have a new bug created with the proper keywords and flags set to trigger a review for their inclusion in the upcoming RHEL 5.3 or other future release. Post a link in this bugzilla pointing to the new issue to ensure it is not overlooked.
For any additional questions, speak with your Partner Manager.
~~ Snapshot 3 is now available ~~
Snapshot 3 is now available for Partner Testing, which should contain a fix that resolves this bug. ISO's available as usual at ftp://partners.redhat.com. Your testing feedback is vital! Please let us know if you encounter any NEW issues (file a new bug) or if you have VERIFIED the fix is present and functioning as expected (add PartnerVerified Keyword).
Ping your Partner Manager with any additional questions. Thanks!
~~ Attention ~~ Snapshot 4 is now available for testing @ partners.redhat.com ~~
Partners, it is vital that we get your testing feedback on this important bug fix / feature request. If you are unable to test, please clearly indicate this in a comment to this bug or directly with your partner manager. If we do not receive your test feedback, this bug is at risk from being dropped from the release.
If you have VERIFIED the fix, please add PartnerVerified to the Bugzilla Keywords field, along with a description of the test results.
If you encounter a new bug, CLONE this bug and request from your Partner manager to review. We are no longer excepting new bugs into the release, bar critical regressions.
Joy has verified this fix present in 5.3 and this is closed on IBM side. But he noticed the ip command in both 5.3 and prior releases need to add ICMP to policy flags and will plan a patch upstream. Please let me know if the PartnerVerified keyword can be added in the RH Issue Tracker bugzilla in the above circumstances.
IBM, Please file new bug(s) for the issues you mention in comment #25. I'll set PartnerVerified keyword for you. Thanks for the feedback!!
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.