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

From: "Tschofenig, Hannes" <[email-masked]>
Date: Sun, 2 Oct 2005 23:02:11 +0200

hi all, 

i would like to respond to the review comments by steve. i have created the corresponding entities in the issue tracker. please find some further comments inline:

> -----Ursprüngliche Nachricht-----
> Von: Margaret Wasserman [mailto:[email-masked]] 
> Gesendet: Sonntag, 11. September 2005 14:52
> An: [email-masked]; [email-masked]; 
> [email-masked]; Tschofenig, Hannes
> Cc: [email-masked]; Henrik Levkowetz; Steve Bellovin; 
> [email-masked]
> Betreff: Fwd: Re: draft-ietf-mip6-firewalls-02.txt
> 
> 
> 
> 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?

stateful packet filtering firewalls turn out to be a problem for mipv6. 
the occurance of tcp and udp traffic allows the firewall to establish state. for tcp more information is available. 
we mentioned the example with tcp only as an illustration how stateful packet filtering firewalls work and why this leads to a problem. 

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

this sentence sounds good to me. let me change the following paragraph from:

"
   Issue 1: When the MN A connects to the network, it should acquire a
      local IP address (CoA), and send a Binding Update to its Home
      Agent to update the HA with its current point of attachment.  The
      Binding Updates and Acknowledgements should be protected by IPsec
      ESP according to the MIPv6 specifications [1].  However, as a
      default rule, many firewalls drop ESP packets.  This may cause the
      Binding Updates and Acknowledgements between the Mobile Nodes and
      their Home Agent to be dropped.
"

to 

"
   Issue 1: When the MN A connects to the network, it should acquire a
      local IP address (CoA), and send a Binding Update to its Home
      Agent to update the HA with its current point of attachment.  The
      Binding Updates and Acknowledgements should be protected by IPsec
      ESP according to the MIPv6 specifications [1].  However, as a
      default rule, many firewalls drop IPsec ESP packets because they cannot determine whether inbound ESP packets are legitimate, since it is difficult or impossible to create useful state by observing the outbound ESP packets. This may cause the
      Binding Updates and Acknowledgements between the Mobile Nodes and
      their Home Agent to be dropped. 
"

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

would it be useful to add the following sentence at the beginning of section 5.1. this would change the text from: 

"
   Let's consider a MN A, in a network protected by firewall(s).
"

to:

"
   Let us consider a MN A in a network protected by a firewall (or even multiple firewalls). 
   Since the firewall is a topological element the protection it offers is based on its packet filter rules because it is part of the protected topology.
"

> >
> >5.2:
> >	In Figure 2, label CN as "A".

fixed. 

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

we know that many firewalls use state sharing already today. 
we agree that there might even be a problem in general. we thought that it might still be good to indicate this problem. 

a side comment since you raised this issue: do you have some statistics that  
a) show how frequent multi-homed networks are
b) tell us how frequently firewall synchronization is used (if there are multiple firewalls)

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

i agree that some network administrators might allow IPsec protected data traffic to known hosts inside their network to bypass. they, however, need to be told that this is an issue with mobile ip. 

to reflect your comment let me make a proposal to change section 5.3 from: 
"
5.3  Scenario where the HA is in a network protected by firewall(s)

   Let's consider a MN moving into a network protected by firewall(s).
   The following issues may exist:

   Issue 1: If the firewall(s) block ESP traffic, many of the MIPv6
      signaling (e.g.  Binding Update, HoT) may be dropped at the
      firewall(s) preventing MN(s) from updating their binding cache and
      performing Route Optimization, since Binding Update, HoT and other
      MIPv6 signaling must be protected by IPsec ESP.

   Issue 2: If the firewall(s) protecting the Home Agent block
      unsolicited incoming traffic (e.g. as stateful inspection packet
      filters do), the firewall(s) may drop connection set up requests
      from CN, and packets from MN.

   Issue 3: If the Home Agent is in a network protected by several
      firewalls, a MN/CN's change of IP address may result in the
      traffic to and from the Home Agent passing through a different
      firewall that may not have the states corresponding to the flows.
      As a consequence, packets may be dropped at the firewall.
"

to:

"
5.3  Scenario where the HA is in a network protected by firewall(s)

   Let's consider a MN moving into a network protected by firewall(s).
   The following issues may exist:

   Issue 1: If the firewall(s) block ESP traffic, many of the MIPv6
      signaling (e.g.  Binding Update, HoT) may be dropped at the
      firewall(s) preventing MN(s) from updating their binding cache and
      performing Route Optimization, since Binding Update, HoT and other
      MIPv6 signaling must be protected by IPsec ESP.

      Network administrators may allow to bypass IPsec ESP protected traffic to a predefined host within their network. 

   Issue 2: If the firewall(s) protecting the Home Agent block
      unsolicited incoming traffic (e.g. as stateful inspection packet
      filters do), the firewall(s) may drop connection set up requests
      from CN, and packets from MN.

      Network administrators may allow to bypass Mobile IP signaling messages to a predefined host within their network.

   Issue 3: If the Home Agent is in a network protected by several
      firewalls, a MN/CN's change of IP address may result in the
      traffic to and from the Home Agent passing through a different
      firewall that may not have the states corresponding to the flows.
      As a consequence, packets may be dropped at the firewall.

      Network administrators may deploy state synchronization mechanisms between firewalls 
      to deal with this problem prior to the introduction of mobility protocols. 
"
> >
> >
> >
> >		--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.

i have added a few lines based on the last comment by steve, which goes into the same direction. 
> 
>    * 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.

the current document covers the 'worst' case. in certain deployment cases things might be simpler if you, for example, use ah instead of esp or if you use the mipv6-auth protocol instead of ikev1/ikev2. 

> 
> (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.1 deals with a mobile node behind a firewall. section 5.4 deals with the mobile node and the home agend being behind a firewall. maybe the headline of section 5.4 could be improved. 

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

that's a good idea. 
fixed. 

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

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

i have added text to this section. please see issue 44 http://www.mip4.org/issues/tracker/mip6/issue44

ciao
hannes

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