Subject: [MEXT] feedback on draft-ietf-firewall-[vendor|admin]-05

From: "Marc Lampo" <[email-masked]>
Date: Mon, 28 Nov 2011 09:15:09 +0100 (CET)

Hello,

Looking at the list archive, I see no comments on these drafts, published
October 17th.
Nor do I find any traces of discussions on IETF-82.

However, from a security point of view, I do have a remark.
In both drafts, the "Security Considerations" state :
(quoting extracts)
... "recommends a liberal setting of firewall rules" ...
... "some malicious traffic may be permitted" ...
... "allow the initiation of Denial of Service attacks against Mobile IPv6
capable nodes" ...

Is this acceptable ?
Being concerned with security, I'd say that these statements as "Security
Considerations"
might lead to the conclusion that these mobility extensions cannot be
used, in practice ?!

We hear that mobile networks might be the first to be IPv6 only (if there
aren't already such networks around)
 --> IPv6 only in mobile nets : the target for Mobility Extensions
We see that more and more banks offer clients for smartphones for Internet
banking
 --> the "correspondent node" might very well be in some bank's DMZ

??? if they, bank security admins, will accept to setup security devices
    in such a way that "firewall rules are liberal"
    and "potentially allow that DOS attacks are started" ???

It is my impression that, to put mobility information so "deep" in the
stack
 - as "extension header" with IPPROTO_NONE in the next header field -
implies that security infrastructure will need quite some CPU resources
to work its way through them.
Wouldn't it have been wiser to assign a (UDP ?) portnumber to the Mobility
"application" ?

Kind regards,

Marc Lampo
Security Officer
 
    EURid
    Woluwelaan 150    
    1831 Diegem - Belgium
    [email-masked]
    http://www.eurid.eu

---

From: <[email-masked]>
Date: Tue, 29 Nov 2011 17:52:30 +0000

Hi Marco,

In I-D: draft-ietf-mext-mip6-tls we do propose the use of UDP
encapsulation for signaling and traffic between the MN and HA. This would
make the processing and firewall rules simpler (UDP port) as you mentioned
in your email.

-Raj

On 11/28/11 2:15 AM, "ext Marc Lampo" <[email-masked]> wrote:

>_______________________________________________
>MEXT mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/mext

---

From: Suresh Krishnan <[email-masked]>
Date: Wed, 30 Nov 2011 16:21:02 -0500

Hi Marc,
  Thanks for your comments. Please see responses inline.

> ... "allow the initiation of Denial of Service attacks against Mobile IPv6

This selective quoting misses out the context. This text only refers to
MIPv6 *signaling* traffic that is *encrypted*. I am not sure what more
can be done here. If you get an encrypted packet at a firewall, you can
either drop it or allow it to pass.

>  --> the "correspondent node" might very well be in some bank's DMZ

These blanket IPsec rules are applicable only for packets to/from the HA
address and not any arbitrary address. They are not relevant to the CNs.

>     and "potentially allow that DOS attacks are started" ???

I am not getting the reference to bank security admins here. The
encrypted packets are between the HA and the MN. So the firewalls that
need to handle them are in the home network (housing the HA) and the
network to which the MN is attached.

> Wouldn't it have been wiser to assign a (UDP ?) portnumber to the Mobility

This is how it is done for DSMIPv6 (port 4191) as described in Section 4.1.

Thanks
Suresh