Re: [MEXT] Comments on draft-ietf-mext-firewall-vendor-03 and admin-03

[[e-mail] (Arnaud Ebalard)]

Hi,

I updated Yaron's address in CC. The one in the draft does not work. I
think he may be able to provide some arguments. Yaron, if you need the
first msg: http://www.ietf.org/mail-archive/web/mext/current/msg04218.html

"QIU Ying" <[e-mail]> writes:

> Most your comments are regarding the vendor-03. I am not in charge this
> draft, but I would like to reply briefly.  Other co-authors might provide
> more feedback later.
>
> Summarily, these 2 drafts suggest the configuration to ensure the success of
> MIPv6 signalling. The generic firewall configuration is beyond the scope.
>
> It is also supposed that null encryption algorithm in ESP is used for MIPv6
> signalling. It is a generic assumption in MIP6.

Maybe I missed something: when was that decided?

IMHO, ESP with NULL encryption is a very specific target (note that I
also followed the discussions on ipsecme ML). If the document targets
specific environments, it should be stated *explicitly*. If it makes the
hypothesis that ESP with NULL encryption is used, it should be stated
*explicitly*.

My opinon (FWIW) is that it is a dangerous hypothesis: ESP is a step
towards E2E security (authentication and encryption). It is associated
with the shift from security functions implemented in the network
towards security functions implemented on end nodes: 

 - Firewall,
 - Anti-virus, Anti-spam, ...
 - System security (work from MS, Google, ...)

Whether network vendors like it or not, this trend is associated with
the inability to implement those functions in the core for the growing
amount of traffic, the growing number of devices and the growing number
of features/protocols.

Regarding Firewalls, additional context is available on end nodes, load
sharing is automatic, this reduces states in the network, ...

Making ESP with NULL encryption the target of the draft in order to
support the limitations of *current (IPv4-oriented)* Firewalls looks
like a bad workaround and not at all like a solution. This will hinder 
deployment of functionalities and also the deployment of E2E security
solutions. This will also hinder the deployment of MIPv6.

To make a comparison, this looks like we are trying to develop a
solution dedicated to cars with only 3 wheels in an automotive context:
very limited in a real world environment.

Considering the purpose of the drafts ("ensure the sucess of MIPv6
signaling"), the message should be clear:

 - MIPv6 relies on ESP (not a limited version) between entities
   (mandatory between MN and HA, optional but potentially useful for the
   rest of the traffic).
 - MIPv6 makes use of exotic IPv6 extension headers (RH2, HAO in
   DestOpt)
 - MIPv6 makes use of a specific upper layer protocol (MH) for some
   features (RO). This protocol may be seen in the network.

Those need to be allowed to pass through in order for MIPv6 to work. I
think that - in its current form - the document does not deliver this
message. The rationale for previous needs and the associated
implications should be discussed in the draft.

Additional responses to your comments are inline below.


>> -----Original Message-----
>> From: Arnaud Ebalard [mailto:[e-mail]]
>> Sent: Tuesday, June 29, 2010 8:24 PM
>> To: [e-mail]
>> Cc: [e-mail]; [e-mail];
>> [e-mail]; [e-mail]; [e-mail]
>> Subject: Comments on draft-ietf-mext-firewall-vendor-03 and admin-03
>> 
>> Hi,
>> 
>> I just read the two documents. Some comments are provided below on
>> inline versions of the drafts but I wanted to make some generic ones
>> before starting.
>> 
>> First, my feedback on deploying MIPv6 in real environments (read
>> environments with devices from major network vendors in the middle) is
>> that you basically face a lot of issues:
>> 
>>  - Cisco PIX firewall dropping RH with no easy way to workaround the
>>    issue (see http://natisbad.org/IRO)
>>  - Nokia (Flexi ISN) GGSN dropping ESP (over IPv6) traffic between the
>>    Gi and Gn (but not in the other direction).
>>  - PMTUD issues (e.g. lack of proper timeout on dynamic session
>>    invalidation on Cisco devices, ...)
>>  - ...
>
> As you pointed out, it is difficult to enumerate all of firewalls. So we
> simply focused on the common firewalls.

My remark was not about listing all firewalls: it was about things which
do not work due to firewalls, with real life examples. I don't care about
the brands. The message is about ESP, RH2/HAO, MH.


>> Additionally, even if some consider firewalls as managed devices, I can
>> say that when you are *really* using a MN on a daily basis and move to
>> various kind of networks, you end up considering that they are unmanaged
>> ones: it's usually impossible to bug someone if your *legitimate*
>> traffic does not pass through due to tight rules (more on this
>> below). The point is that once devices are badly configured (or
>> implement stupid default policies or have buggy implementations), they
>> don't improve security, they just frustrate people by preventing
>> legitimate features and possibly E2E security.
>
> Agree. However, these documents just consider the MIP6 signalling. The
> packets of MIP6 signalling are very small and the signalling processes are
> simply. Hence, opening some special pinholes for these signalling heads
> would not incur considerable security problem.

Trying to statefully filter MIPv6 signaling in the network, all the more
with the hypothesis that ESP is used with NULL encryption does not look
realistic to me.


>> >    Some Mobile IPv6 signalling messages require the use of encryption to
>> >    protect the confidentiality of the payload (e.g. the HoTI and HoT
>> >    messages between the MN and the HA).
>> 
>> Is there are any reason for using HoT and HoTI as examples here instead
>> of BU and BA? Protection of BU/BA by IPsec is mandatory and they are
>> always used by the protocol. Protection of HoT and HoTI is a SHOULD and
>> they are only used for RRP with CN.
>
> It's not example. The message HoTI/HoT is also protected by IPsec between MN
> and HA. If the BU/BA is for CN, it does not go through HA and then not
> protected by IPsec.

ESP (w/ encryption) is needed for generic deployment of MIPv6. Whether
it is for HoT/HoTI, BU/BA exchanged between MN and HA, tunneled data or
other use cases like signaling between MN and CN (see [1] and [2]).

[1]: http://tools.ietf.org/html/draft-ietf-mip6-cn-ipsec-08
[2]: http://tools.ietf.org/html/draft-ebalard-mext-ipsec-ro-01


>> >   The other signalling messages
>> >    allow the use of encryption.  If encryption is being used, it is not
>> >    possible to inspect the contents of the signalling packets.  For
>> >    these messages to get through, a generic rule needs to be added in
>> >    the firewall to let ESP packets through without further inspection.
>> 
>> It should also be noted that if you cannot inspect the content of those
>> packets, then you cannot infer any rule from them. My point is that if
>> you follow SHOULD and MUST from MIPv6 specs, signaling messages are ESP
>> protected and there is nothing a FW can do with those. Said differently,
>> because of previous fact, FW should not some deny by default policies
>> installed in the hope of relaxing them statefully when they see an
>> unprotected signalling message.
>
> It's supposed that ESP uses null encryption algorithm.

That's the point, the hypothesis you make in the draft prevents the
deployment of all kind of encryption for any feature proposed by the
protocol because this implies a default deny policy for ESP traffic w/
meaningful encryption.


>> > 3.  MIPv6 Firewall Primitives
>> >
>> > 3.1.  Requirements
>> >
>> >    This document assumes that the firewalls are capable of deep packet
>> >    inspection at least until the mobility header.
>> 
>> Can you clarify. Do you mean that:
>> 
>>  1) they know how to parse MH and ICMPv6 packets and options
>
> Yes. Answer 1) is the right answer. But it is satisfied that MH can be
> parsed. Parsing much deeper options is not necessary. 

I think I am missing something: the FW sitting in front the HA will
implement rules to parse MH headers protected using ESP w/o
encryption in order to install stateful rules for return traffic *from*
the HA. I don't see what kind of additional protection this brings?

Security Policies on the HA are expected to:

 1) drop unknown ESP packets (FW cannot do that)
 2) drop packets which do not match the policy when received

At the moment (but perhaps I missed something), the FW implementing
those rules in front of the HA is just an artificial addition: it only
increase the amount of running code and the states in the network.


>> > 3.3.  Parsing Mobility Options
>> >
>> >    The Mobility Header can carry additional information in the form of
>> >    mobility options as described in section 6.2 of [RFC3775] and section
>> >    3 of [RFC5555].  Some of these mobility options need to be understood
>> >    for proper creation of state on the firewalls.  Hence firewalls must
>> >    be able to parse the mobility options defined in [RFC3775] and
>> >    [RFC5555].
>> 
>> This is vague. RFC 3775 defines 6 options: Pad1, PadN, Binding Refresh
>> Advice, Alternate Care-of Address, Nonce Indices, Binding Authorization
>> Data.
>
> Just inspect until the mobility header, i.e. Type 1(HoTI), Type 2(CoTI),
> Type 3(HoT), Type 4(CoT), Type 5(BU) and Type 6(BA). No need to inspect the
> parameters you mentioned above.

Well, the subsection is called "Parsing Mobility Options" and the
paragraph tells the reader "Some of these mobility options need to be
understood for proper creation of state on the firewalls" and "Hence
firewalls must be able to parse the mobility options" I list above.


>> >    Such dynamic rules can be timed out after a configurable period
>> >    STATEFUL_PINHOLE_LIFETIME, unless renewed by new mobility messages.
>> >    This document recommends that the default value of
>> >    STATEFUL_PINHOLE_LIFETIME be set to 30 seconds.
>> >
>> >    These dynamic rules MUST be immediately deleted after the return
>> >    message passes through. e.g.  Once a return HoT message for a HoTI
>> >    passes through, the pinhole must be immediately removed.
>> 
>> I guess the stateful filtering your firewall is performing also includes
>> associated traffic, for instance ICMPv6 Packet Too Big Messages (IMHO,
>> this is stupid not to let those pass through, all the more in an IPv6
>> network, but firewalls tend to do that by default). If that is the case,
>> it should be stated in the document. If that is not the case, drop the
>> following comment:
>
> I think the issue of ICMP is beyond the scope. If the ICMP message is a
> response packet, please refer to section 4. If not, the process of ICMP is
> based on the normal confic of the firewall.
>
>> What happens if the router just after the FW returns a Packet Too Big
>> message when routing your HoT. Do you rely on the fact that a HoT
>> packet is less than 1280 bytes long? To make it clear, invalidating a
>> dynamic rules directly after the return packet does not work. A timeout
>> needs to be used.

I don't think the problem of ICMP is beyond scope when the described
mechanism creates the problem: if you invalidate the stateful rule *as
soon as* you see the reply ("immediately removed") . It does not work in
practice for the reason described above. If you need an example, PIX
devices do that for ICMPv6 packets. You need a grace period for removing
the pinhole (or at least the associated "session" on the device).


>> 
>> >  The loss of
>> >    the HoT packet after passing the firewall needs to be handled by the
>> >    original MN retransmitting the HoTI message.
>> 
>> What does it mean? I fail to see the link with the document.
>
> Something regarding timeout, resenting packet, giving up, etc.

Well, this does not clarify the intent of the sentence. If it's just
generalities, no need to keep it.


>> After reading that section, I fail to see what the purpose of the FW is
>> here. What does it defend? Against what? Can that goal be stated
>> explicitly in order to understand what the additional states created in
>> the network are useful for?
>
> The purpose of these documents is not to defend or against any attacks. It
> just ensures that  the MIP6 signalling can go though firewalls with smallest
> pinholes. 

Except for creating the kind of issues we have on IPv4 networks, trying
to lock down the traffic by installing the "smallest pinholes" is IMHO a
bad idea, all the more when:

 - the grounds for doing it are missing
 - it requires to lower the security of filtered protocols
 - it lowers the deployment of new (E22) features and security mechanisms

The firewall in front of my HA only allows IKE and ESP. The IPsec stack
on the HA does the rest.


>> ### Comments on draft-ietf-mext-firewall-admin-03
>>
>> [snip]
>> >    o  Route optimization signaling between MN and CN through HA
>> >    o  Route optimization signaling between MN and CN
>>                            ^^^^^^^^^^
>>                            signalling (a mix of both is used in the
>>                            draft. Is it ok?)
>
> Cannot combine. The first sentence is for HoTI/HoT, while the second
> sentence is for CoTI/CoT and correspond BU/BA.

Sorry, I was unclear on that one: I meant to use either "signaLing" xor
"signaLLing" in the two documents (and not merging the two items)

Cheers,

a+