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

From: "QIU Ying" <[email-masked]>
Date: Mon, 5 Jul 2010 23:39:01 +0800

Hi, Arnaud

Thanks for your detail comments.

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.

Other responses please refer inline. 

> -----Original Message-----
> From: Arnaud Ebalard [mailto:[email-masked]]
> Sent: Tuesday, June 29, 2010 8:24 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked]
> 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.
  
> 
> And that's without even considering configurations issues. 

In fact, these 2 drafts described all possible scenarios, such as MN, HA, CN
are protected by a firewall, respectively. The configuration patterns are
also provided based on the scenarios. 

> BTW, on
> previous issues, if some people from Cisco or Nokia are interested in
> discussing the technical details so that they get fixed, I am happy to
> help.

Yes. I am also happy these documents would be much stronger. 

> 
> 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.
     
> 
> When pushing for filtering rules (in the documents below), the real
> interests (security-wise) should be *explicitly* stated and the possible
> drawbacks (things which may break) should also be considered. Making
> firewalls MIPv6-aware should not result in more difficulty to deploy the
> protocol.
> 
> MIPv6 relies on IPsec/IKE for securing many aspects of the protocol. FW
> should not break that by default.

Agree.

> 
> > 2.  Introduction
> >
> >    Network elements such as firewalls are an integral aspect of a
> >    majority of IP networks today, given the state of security in the
> >    Internet, threats, and vulnerabilities to data networks.  MIPv6
> >    [RFC3775] defines mobility support for IPv6 nodes.  Since firewalls
> >    are not aware of MIPv6 protocol details, they will probably interfere
> >    with the smooth operation of the protocol.  The problems caused by
> >    firewalls to Mobile IPv6 are documented in [RFC4487].
> >
> >    This document presents some recommendations for firewall vendors to
> >    help them implement their firewalls in a way that allows Mobile IPv6
> >    signaling and data messags to pass through.  This document describes
> >    how to implement stateful packet filtering capability for MIPv6.
> >
> >    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.

> 
> >   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.

> 
> > 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. 

>  2) they will be used in environemnts where they have access to
>     unprotected packets, i.e. ones that can be parsed in the network.
> 
> >  It also assumes that
> >    the firewalls are capable of creating filters based on arbitrary
> >    fields based on the contents of a signaling packet.
> >
> > 3.2.  Detecting and parsing the Mobility Header
> >
> >    The Mobility Header is the basic primitive in all MIPv6 signaling
> >    messages.  Thus the firewalls need to be able to recognize the
> >    presence of the mobility header and be able to parse the contents of
> >    the Mobility Header.  The MH is described in section 6.1 of [RFC3775]
> >    and the format of the same is scribed in section 6.1.1 of [RFC3775].
>                                  ^^^^^^^^^
>                                  described
> 
> >    Firewalls need to be able to at least understand the contents of the
> >    MH Type field that describes the type of signaling message carried.
>                                               ^^^^^^^^^^
>                                               signalling
> 
> >
> > 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.     

> 
> For each of them, you should state what the interest of supporting it
> in a firewall (what can be checked? how? What kind of dynamic rules
> could be expected) and the expectation to see those options on the path
> on which you deploy your FW.
> 
> IMHO, there is no use or no expectation
> 
> > 4.  Allowing signaling response packets
> >
> >    The MIPv6 signalling messages are usually performed as a request-
> >    response pair.  The request message is usually allowed by setting up
> >    a static firewall rule to allow the traffic to pass through.  The
> >    response message on the other hand can be dynamically allowed if the
> >    firewall can automatically setup a filter for the response packets
> >    when the request packet passes through.  This is not trivial, but
> >    fortunately is straightforward.
> 
> I don't understand last sentence.
> 
> >    There are 3 message pairs that are of importance to MIPv6 signaling.
> >    They are the BU/BA, HoTI/HoT and  CoTI/CoT pairs.  When the first
> >    message in the pair traverses the firewall in one direction, the
> >    firewall must setup a filter rule to allow the second message
> >    through in the other direction.
> >
> >    Consider a packet that matches a static rule configured on a firewall
> >
> >      Destination Address: Address of HA
> >      Next Header: 50 (ESP)
> >      Mobility Header Type: 5 (BU)
> 
> How will it access the Mobility Header Type if the packet is ESP
> protected?

Null encryption algorithm is used in ESP. The reason to inspect the MH is to
ensure the pinhole is as small as possible.
 
> 
> >    This rule allows a binding update message from a MN to pass through
> >    to the HA.  Once a packet that matches this rule passes through the
> >    firewall, the firewall must setup a dynamic filter for the return
> >    packet
> >
> >      Source Address: Destination Address from Packet
> >
> >      Destination Address: Source Address from Packet
> >      Next Header: 50 (ESP)
> >      Mobility Header Type: 6 (BA)
> >
> >    This rule ensures that the return BA packet will pass through
> >    unhindered.  The rules can be generalized as summarized in the table
> >    below.
> >
> >    +---------------------------------+---------------------------------+
> >    |      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)   |
> >    +---------------------------------+---------------------------------+
> >
> >                       Table 1: Message Pairs in MIPv6
> 
> For HoTI/HoT, if RFC 3775 is followed (Should use ESP), the FW needs to
> be put after the HA to have access to the information.
> 
> For CoTI/CoT, things may be feasible if ESP is not used between the
> peers.
> 
> Additionally, HoTI/HoT and CoTI/CoT are all part of a common mechanism
> (RRP): the possibilities and drawbacks of introducing rules on a single
> part (HoTI/HoT or CoTI/CoT) should be discussed.

The pinholes are just open for above 6 mobility header types. The size is
small and process is simple for these messages. I thought that the section 8
(Security Consideration) should provide the discussion already.
  
> 
> >    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.
> 
> >  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.

> 
> >    A DSMIPv6 client [RFC5555] having been configured with only a v4 CoA,
> >    will tunnel the MIP6 signaling messages to the HA's IPv4 address
> >    using its IPv4 CoA.  These messages are either IP-in-IP encapsulated
> >    (protocol number 4) or UDP&IP encapsulated and sent to the
> >    destination UDP port number 4191.
> >
> >    The firewall SHOULD understand the Binding Update and Biding
>                                                            ^^^^^^^
>                                                            Binding
> 
> >    Acknowledgement Message Extensions and check the status of the F
> >    flag.  If the F flag is set to zero in both the BU and the BA, the
> >    firewall MUST set up a dynamic filter for the return packets:
> >
> >      Destination Address: IPv4 CoA of the MN
> >      Protocol: 4 (IP-in-IP)
> >      Source Address: IPv4 address of the HA
> >
> >    When the F flag is set to 1 in either the BU and BA, the firewall
> >    does not need to take any special action, as the signaling packets
> >    will be UDP encapsulated.
> 
> (not commenting on DSMIP)
> 
> > 5.  Allowing data packets based on signaling
> >
> >    Once the MIPv6 signaling completes, the data traffic can begin to
>                     ^^^^^^^^^
>                     signalling
> 
> >    flow.  The traffic filters for the data traffic can be inferred from
> >    the contents of the signaling messages that setup the session.  This
> >    section describes how firewalls can intelligently setup filters for
> >    data traffic based on signaling traffic.The following example
> >    describes how to setup a filter for allowing incoming route optimized
> >    messages from a CN to an MN after the MN sent a BU message to a CN.
>                            ^^
>                             a
> 
> >
> >    When the BU message from MN to CN (MH Type 5) traverses through the
> >    firewall the firewall extracts the home address (HoA) from the Home
> >    Address Option (section 6.3 of [RFC3775]) of the packet.
> >
> >    The firewall adds the following rule in order to let the return
> >    traffic pass.
> >
> >      Destination Address: Source Address of the packet (MN CoA)
> >      Source Address: Destination Address of packet (CN)
> >      Routing Header Type 2 Address: HoA
> >
> >    This pattern allows all route optimized traffic coming from the CN to
> >    the MN to pass through.
> >
> >    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)
> >      Home Address Dest.  Option: MN HoA
> >
> >    This pattern allows all route optimized traffic coming from the MN to
> >    the CN to pass through.
> >
> >    A firewall protecting the HA can add the following rule on reception
> >    of a HA binding update, in order to let the incoming bi-directional
> >    tunneled traffic pass.
> >
> >      Destination Address: Source Address of the packet (MN HoA)
> >      Source Address: Destination Address of packet (CN)
> >
> 
> 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. 

> 
> > 8.  Security Considerations
> >
> >    This document specifies recommendations for firewall vendors to allow
> >    Mobile IPv6 traffic to pass through unhindered. This document
> >    recommends a liberal setting of firewall rules so that all legitimate
> >    traffic may be allowed to pass.
> 
> I don't think this is what the document currently does. Except for the
> initial "let ESP flow" in the introduction, various rules are added
> without considerations on what they can break or if they can be put in
> place.
> 
> I think it would be more useful to discuss the various aspects of MIPv6
> (MN-HA, MN-CN, MN-MN wrt signalling and data traffic) and explain:
> 
>  - what cannot be filtered (ESP, full RRP, ...)
>  - what is broken by filtering a specific kind of packet
>  - what can be done statefully, what cannot be done statefully
> 
> >    This means that some malicious traffic may be permitted by these
> >    rules.  These rules may allow the initiation of Denial of Service
> >    attacks against Mobile IPv6 capable nodes (the MNs, CNs and the
> >    HAs).
> 
> A more useful discussion here would be on what can and cannot be done
> *in the network* regarding to MIPv6 and what can be done on final
> devices (MN and CN) and the HA.
> 
> It seems that the whole doscument is oriented towards network
> devices. They are not the only firewall available, nor the most useful
> ones in filtering MIPv6 traffic. I also think that what can be achieved
> (delegated) to the IPsec stacks on involved entities should be
> discussed.
> 
> >    One of the main goals of any firewall is to prevent unsolicited
> >    traffic from entering the network.  The proposed solution allows such
> >    traffic into the network, albeit with a number of restrictions.
> >
> >    In a typical enterprise environment, an administrator cannot
> >    distinguish Mobile IPv6 capable nodes from other nodes.  In such a
> >    situation any node in the protected network may end up receiving
> >    unsolicited packets from outside the firewall.  The risk in this case
> >    is that such packets could trigger unknown vulnerabilities in any of
> >    these nodes, causing denial-of-service or worse attacks.  This issue
> >    is compounded in a mobile service provider environment by the risks
> >    specific to such environments like endpoint battery exhaustion and
> >    spectrum misuse.
> 
> DoS on MIPv6 nodes (fixed adddress) attached to a constrained medium
> (3G) is indeed a problem but it is indeed outside the scope of current
> document. Having the ability for a node (MN) to push rules upstream
> (e.g. to its HA) pertaining to its traffic would be something
> interesting.
> 
> 
> 
> 
> 
> 
> 
> 
> ### Comments on draft-ietf-mext-firewall-admin-03
> 
> 
> > 2.  Introduction
> >
> >    Network elements such as firewalls are an integral aspect of a
> >    majority of IP networks today, given the state of security in the
> >    Internet, threats, and vulnerabilities to data networks.  MIPv6
> >    [RFC3775] defines mobility support for IPv6 nodes.  Firewalls will
> >    interfere with the smooth operation of the MIPv6 protocol unless
> >    specific steps are taken to allow Mobile IPv6 signaling and data
> >    messages to pass through the firewall.  The problems caused by
> >    firewalls to Mobile IPv6 are documented in [RFC4487].
> >
> >    This document presents some recommendations for firewall
> >    administrators to help them configure their firewalls in a way that
> >    allows the Mobile IPv6 signaling and data messages to pass through.
> >    This document assumes that the firewalls in question include some
> >    kind of stateful packet filtering capability.  The static rules that
> >    need to be configured are described in this document.  In some
> >    scenarios, the support of additional mechanisms to create pinholes
> >    required for MIPv6 signalling and data traffic to pass through will
> >    be necessary.  A possible solution, describing the dynamic
> >    capabilities needed for the firewalls to create pinholes based on
> >    MIPv6 signalling traffic is described in a companion document
> >    [MIP6FWVENDOR].  Other solutions may also be possible.
> >
> >    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).  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.
> 
> Copied from my review of draft-ietf-mext-firewall-vendor-03 above:
> 
> 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.
> 
> >    o  CoTI: Care of Test Init
>               ^^^^^^^
>               Care-of
> 
> > 4.  Home Agent behind a firewall
> >
> >    This section presents the recommendations for configuring a firewall
> >    that protects a home agent.
> >
> >         +----------------+       +---+
> >         |                |       | A |
> >         |                |       +---+
> >         |   +----+       |      External
> >         |   | HA |    +----+      MN
> >         |   +----+    | FW |                 +---+
> >         |  Home Agent +----+                 | B |
> >         |    of A        |                   +---+
> >         |                |                  External
> >         |                |                    Node
> >         +----------------+
> >         Network protected
> >           by a firewall
> >
> >                       Figure 1: HA behind a firewall
> >
> >    For each type of traffic that needs to pass through this firewall,
> >    recommendations are presented on how to identify that traffic.  The
> >    following types of traffic are considered
> >
> >    o  Signaling between the MN and the HA
> >
> >    o  IKEv2 signaling between MN and HA for establishing SAs
> >
> > 4.1.  Signaling between the MN and the HA
> >
> >    The signaling between the MN and HA is protected using IPSec ESP.
> >    These messages are critical to the MIPv6 protocol and if these
> >    messages are discarded, Mobile IPv6 as specified today will cease to
> >    work.  In order to permit these messages through, the firewall has to
> >    detect the messages using the following patterns.
> >
> >      Destination Address: Address of HA
> >      Next Header: 50 (ESP)
> >      Mobility Header Type: 5 (BU)
> >
> >    This pattern will allow the BU messages from MNs to HA to pass
> >    through.
> 
> Same question as for draft-ietf-mext-firewall-vendor-03: how does the FW
> detect the Mobility Header Type 5 (BU). As said in previous paragraph,
> it is IPsec-protected.
> 
> >    When an HA supporting DSMIPv6 clients is behind firewall, in order
> >    for DSMIPv6 signalling to reach the HA, the firewall has to allow
> >    signaling packets sent to HA's UDP port 4191 to pass through:
> >
> >      Destination Address: IPv4 address of HA
> >      Protocol: 17 (UDP)
> >      Port: 4191
> >
> >    The firewall may also have a rule allowing IP-in-IP encapsulated
> >    traffic to pass through to the HA:
> >
> >      Destination Address: IPv4 address of HA
> >      Protocol: 4 (IP-in-IP)
> >
> >    If the above rule is not created by the firewall, IP encapsulated
> >    DSMIPv6 signalling will not reach the HA.  A client compliant with ,
> >    when it does not get a response to the BU, is supposed to resend the
> >    BU encapsulated into UDP, with destination port 4191.  Thus, even if
> >    the above rule is not created the signaling may pass through with the
> >    (IPv4 HA, UDP 4191) rule.
> 
> (not commenting on DSMIPv6 aspects)
> 
> > 4.2.  IKEv2 signaling between MN and HA for establishing SAs
> >
> >    The MN and HA exchange IKEv2 signaling in order to establish the
> >    security associations.  The security associations so established will
> >    later be used for securing the mobility signaling messages.  Hence
> >    these messages need to be permitted to pass through the firewalls.
> >    The following pattern will detect these messages.
> >
> >      Destination Address: Address of HA
> >      Transport Protocol: UDP
> >      Destination UDP Port: 500
> 
> I think section 4 should also cover at least the following aspects:
> 
>  - RH2 / Destination Option Headers handling for the reasons discussed
>    at the beginning of this email.
>  - Related traffic and more precisely support for error reporting
>    (ICMPv6 Packet Too Big needs to pass through)
>  - What cannot be done in a FW and what needs to be delegated to the HA
>    (ESP protected sigaling traffic).
>  - ...
> 
> > 5.  Correspondent Node behind a firewall
> >
> >    This section presents the recommendations for configuring a firewall
> >    if a node behind it should be able to act as Mobile IPv6 CN.
> >
> >         +----------------+                +----+
> >         |                |                | HA |
> >         |                |                +----+
> >         |                |              Home Agent
> >         |  +---+      +----+               of B
> >         |  |CN |      | FW |
> >         |  | C |      +----+
> >         |  +---+         |                +---+
> >         |                |                | B |
> >         |                |                +---+
> >         +----------------+           External Mobile
> >         Network protected                  Node
> >           by a firewall
> >
> >                       Figure 2: CN behind a firewall
> >
> >    For each type of traffic that needs to pass through this firewall,
> >    recommendations are presented on how to identify that traffic.  The
> >    following types of traffic are considered
> >
> >    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.

> >
> >    o  Binding Update from MN to CN
> >
> >    o  Route Optimization data traffic from MN
> >
> > 5.1.  Route optimization signaling between MN and CN through HA
> >
> >    Parts of the initial route optimization signaling has to pass through
> >    the HA, namely the HoTI and the HoT messages.  Without assistance,
> >    the HoTI message from the HA to the CN is not able to traverse the
> >    firewall.  When only a few priviledged nodes (like servers) are
> >    allowed to be contacted by outside nodes, then the following pattern
> >    will allow the HoTI messages to reach these nodes:
> >
> >       Destination Address: CN Address
> >
> >       Mobility Header Type: 1 (HoTI)
> >
> >    where CN Address describes the address(es) of the priviledged
> >    node(s).  This pinhole allows the HoTI message from the HA to the CN
> >    to traverse the firewall.  The HoT message from the CN to the MN
> >    through the HA can traverse the firewall without any assistance.
> >    Hence no pinhole is required.
> >
> > 5.2.  Route optimization signaling between MN and CN
> >
> >    Route Optimization allows direct communication of data packets
> >    between the MN and a CN without tunnelling it back through the HA.
> >    To get route optimization work, the MN has to send a CoTI message
> >    directly to the CN, which response with a CoT message.  However, a
> >    stateful firewall would prevent the CoTI message to pass through as
> >    there is no established state on the firewall.  When only a few
> >    priviledged nodes (like servers) are allowed to be contacted by
> >    outside nodes, then the following pattern will allow the CoTI
> >    messages to reach these nodes:
> >
> >       Destination Address: CN Address
> >
> >       Mobility Header Type: 2 (CoTI)
> >
> >    where CN Address describes the address(es) of the priviledged
> >    node(s).The CoT message from the CN to the MN can traverse the
> >    firewall without any assistance.  Hence no pinhole is required.
> >
> > 5.3.  Binding Update from MN to CN
> >
> >    After successfully performing the return routability procedure, the
> >    MN sends the BU to the CN and expects the BA.  Since this BU does not
> >    match any previous installed pinhole rules, an additional pinhole
> >    with the following format is required.When only a few priviledged
> >    nodes (like servers) are allowed to be contacted by outside nodes,
> >    then the following pattern will allow the BU messages to reach these
> >    nodes:
> >
> >       Destination Address: CN Address
> >
> >       Mobility Header Type: 5
> >
> >    where CN Address describes the address(es) of the priviledged
> >    node(s).This allows the BU to traverse the firewall and the BA can
> >    pass the firewall without any assistance.  Therefore, the Binding
> >    Update sequence can be performed successfully.
> >
> > 5.4.  Route Optimization data traffic from MN
> >
> >    Also the Route Optimization data traffic from MN directly to the CN
> >    can not traverse the firewall without assistance.  A dynamically
> >    created pinhole such as the one specified in [MIP6FWVENDOR] will
> >    allow this traffic to pass.
> 
> What's the status about ESP traffic in section 5? It should be stated
> explicitly that ESP is allowed in both directions (IMHO).
> 
> 
> > 6.  Mobile Node behind a firewall
> >
> >    This section presents the recommendations for configuring a firewall
> >    that protects the network a mobile node visiting.
> >
> >         +----------------+       +----+
> >         |                |       | HA |
> >         |                |       +----+
> >         |                |      Home Agent
> >         |  +---+      +----+      of A               +---+
> >         |  | A |      | FW |                         | B |
> >         |  +---+      +----+                         +---+
> >         |Internal        |                         External
> >         |   MN           |                           Node
> >         |                |
> >         +----------------+
> >         Network protected
> >           by a firewall
> >
> >                       Figure 3: MN behind a firewall
> >
> >    For each type of traffic that needs to pass through this firewall,
> >    recommendations are presented on how to identify that traffic.  The
> >    following types of traffic are considered
> >
> >    o  Signaling between MN and HA
> >
> >    o  Route Optimization Signaling between MN and CN
> >
> >    o  IKEv2 signaling between MN and HA for establishing SAs
> >
> > 6.1.  Signaling between MN and HA
> >
> >    As described in Section 4.1, the signaling between the MN and HA is
> >    protected using IPSec ESP.  Currently, a lot of firewalls are
> >    configured to block the incoming ESP packets.  Moreover, from the
> >    view of the firewall, both source and destination addresses of these
> >    messages from/to mobile node are variable.  Fortunately, for a
> >    stateful firewall, if the initial traffic is allowed through the
> >    firewall, then the return traffic is also allowed.  A mobile node is
> >    always the initiator for the BU.  Since MN's CoA is not able to be
> >    known in advance, the firewall can use following patterns to permit
> >    these messages through.
> >
> >      Source Address: Visited subnet prefix
> 
> It's not very clear. What is said is that the MN will be able to use ESP
> with anyone if it initiates the comunication. 

Yes.

> But if someone tries and
> contact it using ESP in some way, this will not work. 

Not exactly. If the ESP message is response, not drop. Otherwise, drop. 

Regards
Qiu Ying

>That's a broken by
> default situation. In most environment where MN are, killing incoming
> ESP is preventing secure communications from the outside world.
> 
> The only interest of dropping ESP traffic from the outside world on the
> FW is to prevent possible DoS against the MN if its medium has low
> bandwdith (3G, ...). Otherwise, ESP traffic that hits the MN is simply
> dropped by the stack. One of the meaning of ESP traffic is that
> *Security Policies* are in place between the receiver and the emitter,
> otherwise this traffic will be dropped by the receiver.
> 
> I don't argue against the idea of filtering ESP but I think we should be
> careful in pushing a default stateful filtering of it in network. ESP is
> E2E.
> 
> >      Destination Address: Address of HA
> >      Next Header: 50 (ESP)
> >      Mobility Header Type: 5 (BU)
> >
> >    This pattern will allow the Binding Update packets to pass through
> >    the firewall.  Then the return packets (BA from HA to MN) will also
> >    able to pass through accordingly.
> 
> How can BU be seen if the packet is ESP protected.
> 
> > 6.2.  Data packets between DSMIPv6
> >
> >    In case of a DSMIPv6 client with only a v4 CoA, the dynamic rules set
> >    by the firewall to allow DSMIPv6 signalling packets pass through
> >    between the MN and the HA, may time out and be closed.  If that
> >    happens, data packets sent by a CN to the MN through the HA will not
> >    reach the MN.  Therefore, the firewall will need to set a static rule
> >    to allow data packets sent from the HA's IPv4 address to the MN's
> >    IPv4 CoA using either protocol number 4 (IP-in-IP encapsulation) or
> >    17 (UDP), depending on the value of the F bit, to pass through.  The
> >    UDP port numbers for the rule are to be read from the BU/BA message
> >    exchange [RFC5555].  When the firewall chooses to create static rules
> >    (without traffic based timeout) for allowing DSMIPv6 signalling pass
> >    between the MN and HA, then no further rules need to be created by
> >    the firewall, as data packets follow the same tunnel as the
> >    signaling.
> 
> (not commenting on DSMIPv6 aspects)
> 
> > 6.3.  Signaling between MN and CN
> >
> >    Route Optimization allows direct communication of data packets
> >    between the MN and a CN without tunneling it back through the HA.  It
> >    includes 3 pairs of messages: HoTI/HoT, CoTI/CoT and BU/BA.  The
> >    first pair can pass through the firewall using the pattern described
> >    in section 5.1.  Here we discuss CoTI/CoT and BU/BA messages.
> >    Following pattern permits these messages through the firewall.
> >
> >    Source Address: Visited subnet prefix
> >      Mobility Header Type: 2 (CoTI)
> >
> >    Source Address: Visited subnet prefix
> >      Mobility Header Type: 5 (BU)
> >
> >    This pattern allows the initial messages (CoTI and BU) from the MN to
> >    the CN pass through the firewall.  The return messages (CoT and BA)
> >    from the CN to the MN can also passes through the firewall
> >    accordingly.
> >
> > 6.4.  IKEv2 signaling between MN and HA for establishing SAs
> >
> >    The MN and HA exchange IKEv2 signaling in order to establish the
> >    security associations.  The security associations so established will
> >    later be used for securing the mobility signaling messages.  Due to
> >    variable source/destination IP addresses and MN always as initiator,
> >    the following pattern will let the negotiation pass.
> >
> >    Source Address: Visited subnet prefix
> >    Transport Protocol: UDP
> >    Destination UDP Port: 500
> 
> ok.
> 
> > 10.  Security Considerations
> >
> >    This document specifies recommendations for firewall administrators
> >    to allow Mobile IPv6 traffic to pass through unhindered.  Since some
> >    of this traffic is encrypted it is not possible for firewalls to
> >    discern whether it is safe or not.  This document recommends a
> >    liberal setting so that all legitimate traffic can pass.  This means
> >    that some malicious traffic may be permitted by these rules.  These
> >    rules may allow the initiation of Denial of Service attacks against
> >    Mobile IPv6 capable nodes (the MNs, CNs and the HAs).
> 
> I think the status on ESP (at least) should be made clear: reading this
> section, I am under the impression that letting ESP pass through is a
> problem.
> 
> Unlike usual upper layer protocols (TCP, UDP, ...) on which nodes can be
> targeted by remote hosts, ESP requires previous trust establishment
> between the peers. Sure, this is not controlled by the firewall between
> the peers but this involves either local configuration or global
> management on both host.
> 
> I think this should be considered and ESP should be allowed to pass
> through in both directions by default, except otherwise specified. This
> should be stated explicitly in the paragraph above instead of the
> confusing:
> 
>   "Since some of this traffic is encrypted it is not possible for
>   firewalls to discern whether it is safe or not. This document
>   recommends a liberal setting so that all legitimate traffic can
>   pass"
> 
> 
> 
> After reading both documents, it is difficult for me to tell if all the
> issues presented in RFC 4487 are covered and in which fashion. It should
> be clear what works and what does not due to the things proposed in the
> documents. Maybe the issues presented in RFC 4487 should be discussed in
> an *explicit* fashion in both documents.
> 
> Hope that helps,
> 
> Cheers,
> 
> a+

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."

---

From: [email-masked] (Arnaud Ebalard)
Date: Wed, 07 Jul 2010 17:19:33 +0200

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

> 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.

> 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.

> 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.

> and HA. If the BU/BA is for CN, it does not go through HA and then not

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

> 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.

> 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.

> 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.

>> dynamic rules directly after the return packet does not work. A timeout

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).

> 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.

> just ensures that  the MIP6 signalling can go though firewalls with smallest

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.

>> [snip]

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+