[Mip6-firewall] New versions of firewall drafts -- vendor draft
Yaron Sheffer
yaronf at checkpoint.com
Thu Nov 15 06:48:21 EST 2007
Hi,
nowadays ESP-null is commonly used for traffic integrity protection,
rather than AH. ESP-null means ESP with a null *encryption* algorithm,
but with a real authentication algorithm (e.g. SHA-1). I believe this is
what RFC 3776 recommends for BU/BA.
BTW, ESP with encryption but no integrity protection is probably never
"the right thing".
Thanks,
Yaron
QIU Ying wrote:
> 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 <mailto:yaronf at checkpoint.com>
> *To:* Suresh Krishnan <mailto:suresh.krishnan at ericsson.com>
> *Cc:* QIU Ying <mailto:qiuying at i2r.a-star.edu.sg> ; Niklas
> Steinleitner <mailto:steinleitner at cs.uni-goettingen.de> ;
> mip6-firewall at zeke.ecotroph.net
> <mailto: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
>
[deleted]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://zeke.ecotroph.net/pipermail/mip6-firewall/attachments/20071115/a9e39aea/attachment-0001.html
More information about the Mip6-firewall
mailing list