[Mip6-firewall] New versions of firewall drafts -- vendor draft
QIU Ying
qiuying at i2r.a-star.edu.sg
Thu Nov 15 03:01:34 EST 2007
Hi, Suresh and Yaron,
> I thought so too and that is why in v01 of the combined draft I did
> not have this, but after another through reading of RFC3775 I determined
> that the IPSec ESP is used only for authentication and not for
> encryption. Hence the new text.
>
Which sentences in RFC 3775 make this judgment?
> So: encryption for return routability, authentication only for BU/BA. But
> note that the RFC does not stop you from encrypting BU/BA if you want to.
If the claim were correct, how to send the encrypted HoTI from MN to the HA behind a firewall?
Perhaps, there is confusion between the AH part in ESP (RFC 2406) and the AH header (RFC2402).
In ESP (RFC2406), the packet structure likes below
AFTER APPLYING ESP
---------------------------------------------------------
IPv6 | orig |hop-by-hop,dest*,| |dest| | | ESP | ESP|
|IP hdr|routing,fragment.|ESP|opt*|TCP|Data|Trailer|Auth|
---------------------------------------------------------
|<---- encrypted ---->|
|<---- authenticated ---->|
The ESP authentication is not compulsory. The encryption can be employed alone. But MIPv6 documents (RFC3775 and RFC 3776) do not allow this mode. That is why the sentence "MUST use a non-null payload authentication algorithm" is appeared.
If only authentication is used, the protocol should be RFC 2402 which packet structure is
AFTER APPLYING AH
------------------------------------------------------------
IPv6 | |hop-by-hop, dest*, | | dest | | |
|orig IP hdr |routing, fragment. | AH | opt* | TCP | Data |
------------------------------------------------------------
|<---- authenticated except for mutable fields ----------->|
Although RFC3775 allows to use the AH protocol of RFC 2402, the most usage is still ESP protocol of RFC 2406 in which the mobility header is in ciphertext. Please refer to section 5.1, RFC3775:
5.1. Binding Updates to Home Agents
The mobile node and the home agent MUST use an IPsec security
association to protect the integrity and authenticity of the Binding
Updates and Acknowledgements. Both the mobile nodes and the home
agents MUST support and SHOULD use the Encapsulating Security Payload
(ESP) [6] header in transport mode and MUST use a non-NULL payload
authentication algorithm to provide data origin authentication,
connectionless integrity and optional anti-replay protection. Note
that Authentication Header (AH) [5] is also possible but for brevity
not discussed in this specification.
Regards
Qiu Ying
----- Original Message -----
From: Yaron Sheffer
To: Suresh Krishnan
Cc: QIU Ying ; Niklas Steinleitner ; mip6-firewall at zeke.ecotroph.net
Sent: Thursday, November 15, 2007 12:15 AM
Subject: Re: [Mip6-firewall] New versions of firewall drafts -- vendor draft
Hi Suresh, Ying,
this seems to be more of an oral tradition... It is not very clear from RFC 3775. The companion document RFC 3776 is a little clearer, it states (Sec. 4.3):
o When securing Binding Updates, Binding Acknowledgements, and prefix discovery, both the mobile nodes and the home agents MUST support and SHOULD use the Encapsulating Security Payload (ESP) [3] header in transport mode and MUST use a non-null payload authentication algorithm to provide data origin authentication, connectionless integrity and optional anti-replay protection.
Mandatory support for encryption and integrity protection algorithms is as defined in RFC 2401 [2], RFC 2402 [8], and RFC 2406 [3]. Care is needed when selecting suitable encryption algorithms for ESP, however. Currently available integrity protection algorithms are in general considered to be secure. The encryption algorithm, DES, mandated by the current IPsec standards is not, however. This is particularly problematic when IPsec security associations are configured manually, as the same key is used for a long time.
o Tunnel mode IPsec ESP MUST be supported and SHOULD be used for the protection of packets belonging to the return routability procedure. A non-null encryption transform and a non-null authentication algorithm MUST be applied.
So: encryption for return routability, authentication only for BU/BA. But note that the RFC does not stop you from encrypting BU/BA if you want to.
Yaron
Suresh Krishnan wrote:
Hi Ying,
I thought so too and that is why in v01 of the combined draft I did not have this, but after another through reading of RFC3775 I determined that the IPSec ESP is used only for authentication and not for encryption. Hence the new text.
Cheers
Suresh
QIU Ying wrote:
Hi, Suresh and Yaron
Regarding the pattern in section 4, if I am not wrong, the mobility header is encrypted by ESP. So a firewall is not able to detect the mobility header in the BU/BA messages as well as in the HoTI/HoT messages between MN and HA. The proposed rule here does not work. Due to the limited of BCP, I do not think that a firewall could distinguish the IPSec packets with mobility header from normal IPSec packets. Therefore we might just suggest HA to protect itself.
I also support Yaron's viewpoints:
>>1. Sec. 3.1: why is deep packet inspection "of arbitrary depth" required? This requirement could result in a number of security vulnerabilities around DOS and fragmentation. And all we really require is inspection of the mobility headers!
The words of "arbitrary depth" is too aggressive. How deep do you want? For our purpose, the sentence "inspection of the mobility headers" is enough.
>>2. Sec. 4: in fact, perhaps we should break up this section into two: "protecting the HA" and "protecting the MN". We have different assumptions about their ability to secure themselves, and can possibly provide different solutions.
Yes, it is better to describe the different scenarios in different sections in order to easily understand, such as we done in admin draft. I guess the focus of current section 4 is more on protected HA while section 5 is on protected CN.
>>3. Sec. 5: For security reasons, state should only be established by the return packet, i.e. based on BA, not BU.
Right, using BA is better since BA is from inner.
>>4. Sec. 5: When does the FW remove this filter? Actually the same question is valid for the filters defined in Sec. 4.
I think that the protected node (HA, CN, or MN) can send a notice to its firewall to remove the related rules when the entry in binding cache is expired (<= 420 seconds).
But following statements need more clarify.
>>1. Sec. 4: The level of detail in this section is redundant, and actually requires the firewall to provide unnecessary protections. Once we allow any BU from the outside into the HA, we might as well allow *any* mobility header into the HA, and leave it to the HA to manage its mobility state (active sessions).
Please note that BU to HA is encrypted by IPSec. The FW can not detect whether a packet is BU message or not.
>>2. General: We should at least RECOMMEND that the FW drops all unprotected (non-ESP) mobility messages going to hosts.
Why need this RECOMMEND? In fact, most of mobility messages are non-ESP, such as, for HA: HoT from CN; for MN, CoTI/COT and BU/BA to/from CN; for CN all of messages.
>>3. Sec. 5: This section assumes that the mobility signaling is protected by ESP-null, i.e. is unencrypted. Please make it explicit in Sec. 4 that the FW MUST enforce this condition (by parsing the inner packet of the BU/BA messages).
BU to HA is protected by ESP, but BU to CN is non-ESP.
Regards
QIu Ying
----- Original Message -----
*From:* Yaron Sheffer <mailto:yaronf at checkpoint.com>
*To:* Niklas Steinleitner <mailto:steinleitner at cs.uni-goettingen.de>
*Cc:* mip6-firewall at zeke.ecotroph.net
<mailto:mip6-firewall at zeke.ecotroph.net>
*Sent:* Tuesday, November 13, 2007 7:43 PM
*Subject:* Re: [Mip6-firewall] New versions of firewall drafts
Hi Suresh,
here are a few more comments to the vendor draft:
* Abstract: typo "messags".
* Sec. 3.1: why is deep packet inspection "of arbitrary depth"
required? This requirement could result in a number of
security vulnerabilities around DOS and fragmentation. And all
we really require is inspection of the mobility headers!
* Sec. 3.2: typo "og"
* General: I think we need a section about architecture, or what
are our working assumptions. For example, HA is in the
protected network, HoA or MN or both are outside the protected
network; Route optimization is required; HA can protect
itself. Are we covering all 4 scenarios of RFC 4487, Sec. 5?
* General: aren't we being too positive :-) ? At least the
security considerations should talk about what types of
mobility headers should be allowed to non-HA hosts. Do we
assume that *all* hosts can protect themselves as well as the
HA? We should at least RECOMMEND that the FW drops all
unprotected (non-ESP) mobility messages going to hosts.
* Sec. 4: The level of detail in this section is redundant, and
actually requires the firewall to provide unnecessary
protections. Once we allow any BU from the outside into the
HA, we might as well allow *any* mobility header into the HA,
and leave it to the HA to manage its mobility state (active
sessions).
* Sec. 4: in fact, perhaps we should break up this section into
two: "protecting the HA" and "protecting the MN". We have
different assumptions about their ability to secure
themselves, and can possibly provide different solutions. For
example, we can allow BU into the MN only when it is preceded
by the HOT/COT sequence.
* Sec. 5: This section assumes that the mobility signaling is
protected by ESP-null, i.e. is unencrypted. Please make it
explicit in Sec. 4 that the FW MUST enforce this condition (by
parsing the inner packet of the BU/BA messages).
* Sec. 5: For security reasons, state should only be established
by the return packet, i.e. based on BA, not BU.
* Sec. 5: When does the FW remove this filter? Actually the same
question is valid for the filters defined in Sec. 4.
* Security considerations: please add "In addition, allowing
arbitrary mobility traffic into firewall-protected nodes
allows attackers to exploit security vulnerabilities that may
exist on these nodes."
I'll be happy to be listed as coauthor.
Thanks,
Yaron
Niklas Steinleitner wrote:
Hi Suresh, all,
Hi Folks,
I have managed to write up some new text for the vendor
document and removed some stuff from the admin document (the
dynamic part). Can you please go over the documents and let me
know if you have any comments.
some comments to the vendor draft:
Section 3.2:
... type og signaling ... = type *of *signaling
Section 4:
- in the table you swap CoT and CoTI!
right would be:
+---------------------------------+---------------------------------+
| Passing packet MH Type | Setup return filter with MH |
| | Type |
+---------------------------------+---------------------------------+
| Mobility Header Type:1(HoTI) | Mobility Header Type:3(HoT) |
| | |
| Mobility Header Type:2(CoTI) | Mobility Header Type:4(CoT) |
| | |
| Mobility Header Type:5(BU) | Mobility Header Type:6(BA) |
+---------------------------------+---------------------------------+
- There is a needless blank line within the second pinhole format ;-)
Section 5:
This section only specifies how to install a pinhole for the data
traffic from the CN to the MN to pass through.
A second pinhole installed at the event of receiving a BU would
also allow the data traffic from the MN to the CN to traverse the
firewall.
My proposal:
...
Additionally, the firewall adds a second rule in order to let the data traffic from the MN to the CN pass through.
Source Address: Source Address of the packet (MN CoA)
Destination Address: Destination Address of packet (CN)
Next Header: IPv6 Destination Options Header(60)
Destination Address in Dest. Opts. Header: HoA
This pattern allows all route optimized traffic coming from the MN to the CN to pass through.
Regards,
Niklas
If you want to be included in the author list of the vendor
document, please let me know.
Thanks
Suresh
------------------------------------------------------------------------
_______________________________________________
Mip6-firewall mailing list
Mip6-firewall at zeke.ecotroph.net
https://zeke.ecotroph.net/mailman/listinfo/mip6-firewall
-- Niklas Steinleitner Tel: +49 551 3913583
Institute for Informatics steinleitner at cs.uni-goettingen.de
University of Göttingen http://www.tmg.informatik.uni-goettingen.de
Lotzestrasse 16-18
D-37083 Göttingen, Germany
Scanned by Check Point VPN-1 UTM NGX R65 with Messaging Security
------------------------------------------------------------------------
_______________________________________________
Mip6-firewall mailing list
Mip6-firewall at zeke.ecotroph.net
https://zeke.ecotroph.net/mailman/listinfo/mip6-firewall
------------------------------------------------------------------------
_______________________________________________
Mip6-firewall mailing list
Mip6-firewall at zeke.ecotroph.net
https://zeke.ecotroph.net/mailman/listinfo/mip6-firewall
------------ Institute For Infocomm Research - Disclaimer -------------This email is confidential and may be privileged. If you are not the intended recipient, please delete it and notify us immediately. Please do not copy or use it for any purpose, or disclose its contents to any other person. Thank you.--------------------------------------------------------
------------------------------------------------------------------------
_______________________________________________
Mip6-firewall mailing list
Mip6-firewall at zeke.ecotroph.net
https://zeke.ecotroph.net/mailman/listinfo/mip6-firewall
Scanned by Check Point VPN-1 UTM NGX R65 with Messaging Security
------------ Institute For Infocomm Research - Disclaimer -------------This email is confidential and may be privileged. If you are not the intended recipient, please delete it and notify us immediately. Please do not copy or use it for any purpose, or disclose its contents to any other person. Thank you.--------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://zeke.ecotroph.net/pipermail/mip6-firewall/attachments/20071115/452be00f/attachment-0001.html
More information about the Mip6-firewall
mailing list