Subject: Re: [Mip6] Fwd: Re: draft-ietf-mip6-firewalls-02.txt

From: QIU Ying <[email-masked]>
Date: Mon, 12 Sep 2005 19:22:31 +0800

Hi, all

In Steve's review:
>What I'd really like to see in this document, if possible, is a set of
>rules and algorithms, as suggestions for site administrators and
>MIPv6-aware firewall vendors.  But maybe that should be published
>separately.

Yes, there is a separate draft about this issue @
http://www.ietf.org/internet-drafts/draft-qiu-mip6-mobile-firewall-01.txt.
It proposes how to manage a set of rules for an individual MN by its
administrator when the MN roams. If we simply port the concept of current
firewall to mobile environment, a MN (e.g. teens) would be controlled by a
set of firewall rules when it is in school, and then be controlled by
another set of rules when it roams to a shopping mall. As we know, the
restrictions of firewall in shopping mall are much weaker than the ones in
school. Thus, teens can not be protected expectantly as the administrators
(e.g. their parents) hope.

The proposed approach makes the MN can be always controlled and protected by
a set of rules that its administrator specified, no matter where the MN
roams. In the draft, the firewall is not only a topological element of the
visited network, but also an extensive topological element of its home
network.

Regards
Qiu Ying

Date: Sun, 11 Sep 2005 08:51:30 -0400
From: Margaret Wasserman <[email-masked]>
Subject: [Mip6] Fwd: Re: draft-ietf-mip6-firewalls-02.txt
To: [email-masked], [email-masked],
[email-masked], [email-masked]
Cc: [email-masked], [email-masked], Henrik Levkowetz
<[email-masked]>, Steve Bellovin <[email-masked]>
Message-ID: <p062007cbbf49d55eb880@[192.168.2.7]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Hi Franck, Stefano, Raj and Hannes,

As part of AD Review on draft-ietf-mip6-firewalls-02.txt, I solicited
reviews from Henrik Levkowetz and Steve Bellovin.  I have attached
both Steve's and Henrik's reviews below.  Spencer Dawkins also posted
a gen-art review of this draft (also attached).

As you can see, all three reviewers believe that this document is
good work and is close to ready for publication, but they each made a
few minor corrections or editorial suggestions.

When a new version is available that addresses all of these comments,
we should be ready to send this document to the IESG for
review/approval.

Thanks,
Margaret

Steve's Review:

>It's a pretty good document; I'm glad to see it appearing at last.
>I've noted a few clarifications that might help.
>
>What I'd really like to see in this document, if possible, is a set of
>rules and algorithms, as suggestions for site administrators and
>MIPv6-aware firewall vendors.  But maybe that should be published
>separately.
>
>
>
>Section 4:
> Some firewalls check TCP sequence numbers as well.
>
> Is UDP behavior significant here?  Application-level proxies for
> all sorts of protocols?
>
>5.1:
> It's not so much that firewalls drop ESP by default, it's that
> they can't tell if inbound ESP packets are legitimate, since
> there's no useful state created by the outbound ESP packets.
>
> A more general analysis of the issues presented by 5.1 is that
> firewalls are topological elements, not logical ones.  Thus, an
> MN behind a firewall is protected by it/subject to its rules,
> because it's part of the protected topology.  The particular
> issues discussed here are just special cases of that situation.
>
>5.2:
> In Figure 2, label CN as "A".
>
> Issue 3: In many environments with more than one firewall, they
> already share state.  This is a necessity because routing is
> generally asymmetric.  Consider this:
>
>
>       +----------------+
>       |                |
>       |        A      FW1
>       |                |
>       |                |
>       |                |
>       |                |
>       |                |
>       |               FW2      B
>       |                |
>       +----------------+
>
> A is closer to FW1, so its packets exit via FW1.  B is closer
> to FW2, and they advertise the same CIDR block, so the return
> packets will try to go that way.  That fails unless there's
> state-sharing, without any mobility.
>
>5.3:
> It's generally safe to permit ESP traffic to a known-locked down
> host.  If there's a generic HA, it can be a valid recipient of
> IPsec without compromising network security.  The same applies
> to Issue 2.  Issue 3 is the same situation described earlier.
>
>
>
> --Steven M. Bellovin, http://www.cs.columbia.edu/~smb
>

Henrik's Review:

     The document points out real problems, and is reasonably well
written and formulated.

In summary, I think that

   * These are valid problems

   * While the problems described in 5.1, 5.2 and 5.4 may require
     product and protocol modifications, the problems in 5.3 have
     more a character of installation and configuration mistakes,
     and should maybe be labelled as such.

   * MIPv6 permits the use of AH as an alternative to ESP in some
     cases - I wonder if this document should cover this case, as
     well.  I believe that AH may have less problems than ESP, but
     it also gives less protection.  ESP is in particular recommended
     for the HoT and HoTI messages between HA and MN.

(Going into solution space, which doesn't belong in this document,
  I observe that several of the problems associated with route-
  optimised traffic might be solved with an approach similar to that
  used by Teredo.)

Minor comments:

Section 4:

         This section lacks an expansion of HoT. However, if each
abbreviation is expanded on the first of the first few
instances of use, I'd probably be just as happy without
this section.

Section 5.1:

>  5.1  Scenario where the Mobile Node is in a network protected by
>       firewall(s)

It's in Section 5.4, actually.

Section 5.2:

I'd be happier if you did not use the designation 'A' for the
  CN here, after having used 'A' for the MN in Section 5.1.
  Maybe call the nodes 'C' and 'D' here instead?

Section 5.2, para. 22:

>        The HoTI is a Mobility Header packet, and the protocol type
>        differing from the existing states (2), the HoTI packet will also
>        be dropped.

Above sentence is not well formed.
s/the protocol type differing/as the protocol type differs/

Section 5.3, para. 2:

>     Issue 1: If the firewall(s) block ESP traffic, many of the MIPv6
>        signaling (e.g.  Binding Update, HoT) may be dropped ...
...snip...
>        performing Route Optimization, since Binding Update, HoT and other
>        MIPv6 signaling must be protected by IPsec ESP.

I don't see how this differs from Section 5.1, and don't see
  that it belongs here.

Henrik

Spencer's Review:

From: Spencer Dawkins <[email-masked]>
To: Gen-Art Mailing List <[email-masked]>
CC: Margaret Wasserman <margaret...snip... Gopal Dommety
<[email-masked]>
Subject: Gen-ART Review of draft-ietf-mip6-firewalls-02.txt

Background for those on the CC list, who may be unaware of GenART:
GenART is the Area Review Team for the General Area of the IETF.  We
advise the General Area Director (i.e. the IETF/IESG chair) by
providing more in depth reviews than he could do himself of documents
that come up for final decision in IESG telechat.  I was selected
as the GenART member to review this document.  Below is my review,
which was written specifically with an eye to the GenART process, but
since I believe that it will be useful to have these comments more
widely distributed, others outside the GenART group are being copied.

Intended status: Informational

Summary - this document is very close to being ready for publication
as Informational.

I don't believe that Gen-ART reviews for Informational documents need
to say much more than this, but, since I'm typing...

- The document is clearly written and well-organized. Other reviewers
might push back on the breezy English style, but I like it.

- The first time there's a clue that firewalls are problematic for
NON-mobile users is in the Conclusion:

   Current firewalls may not only prevent route optimization but may
   also prevent regular TCP and UDP sessions from being established in
   some cases.  This document describes some of the issues between the
   Mobile IPv6 protocol and current firewall technologies.

It might be nice to call this issue out earlier in the draft, so that
it's more obvious what ADDITIONAL problems happen when you go mobile.
Firewalls that drop ESP by default, for instance, are problematic for
non-mobile users - stuff like that.

- The stated goal for this document is to enable futher discussion; I
didn't see any thought given to firewalls in transit networks between
the home, visited, and correspondent networks, and I'll bet transit
networks will have something like firewalls in place, in at least
some environments. Even a statement that says "we don't think
firewalls in transit networks will add any requirements for further
work" would be useful.

- The assumption that issues called out in this draft will be solved
in MIP6 is stated at the end of the abstract. Although BEHAVE
explicitly declares firewalls to be out of scope, it seems that
what's needed is something like BRIDE of BEHAVE, developing BCP
recommendations for firewall types, just as BEHAVE is doing for NAT
types...

Thanks,

Spencer

_______________________________________________
Mip6 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mip6