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

From: Henrik Levkowetz <[email-masked]>
Date: Sat, 01 Oct 2005 09:48:33 +0200

on 2005-10-01 04:27 Franck Le said the following:

>> Henrik's Review:
> [..]
>> * 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 agree with you. I was just afraid that we may start discussing
> solutions but we can add few sentences to highlight these
> differences. We could explain in the conclusion that "Some of the
> issues described in this document may require changes to firewalls or
> to the protocols. Others may only require the appropriate rules and
> configuration to be in place."

That might be good, but I was actually aiming for some text at the start
of 5.3 that indicated that it's in a different class, so that it's clear
when you read the text that this one is a bit different.

>> * 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.
> 
> I agree with your comment and analysis. As you pointed out, AH is
> permitted in the MIPv6 spec., however it seems that the
> recommendation for ESP was stronger. For this reason, we focused on
> ESP.

Maybe add a comment (in the Security Considerations Section?) to this
effect?

<snip> points where we seem to agree

>> 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.
> 
> The issues are similar as you pointed out. However the firewall in
> section 5.1 is the one protecting the MN (e.g. FW in the visited
> network) while the firewall in section 5.3 is the one protecting the
> HA.
> 
> I hope this clarifies the intentions. However I agree that the
> current text can be confusing.
> 
> Therefore, at the beginning of section 5.3, we will sub /Let's
> consider a MN moving into a network protected by firewall(s). The
> following issues may exist:/ with /In the scenarios where the Home
> Agent is in a network protected by firewall(s), the following issues
> may exist:/
> 
> and in issue 1, we will sub /If the firewall(s) block ESP traffic/ by
> /If the firewall(s) protecting the Home Agent block ESP traffic/> 
> Would this be clearer?

That might work.  I'd like to see it in context when you have a new
rev. ready.

> Thank you again for all your comments!

You're welcome :-)

	Henrik

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

---

From: "Franck Le" <[email-masked]>
Date: Fri, 30 Sep 2005 22:27:41 -0400 (EDT)

Hello,

Thank you Margaret, Steve, Henrik and Spencer for reviewing the document and for all your comments.

Please find below few questions to make sure I correctly understood your
suggestions, and on ways to incorporate them.

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

The objective of this I-D from the perspective of the MIP6 WG and the MIP6 protocol was to raise the awareness w.r.t the issues that firewalls raise in deployment environments. To this end the I-D captures the scenarios and the problems that are posed by the existence of firewalls. The guidelines for firewall administrators and vendors would be potentially a separate document that describes how the issues posed in this I-D may be addressed. While the authors agree that such a document is useful and should be written, we believe that this is a followup to the current I-D and one that can be done independently.

> Section 4: Some firewalls check TCP sequence numbers as well.
> Is UDP behavior significant here?  Application-level proxies for all sorts
> of protocols?

Yes, firewalls now offer a wide range of features. However we did not describe all of them. We instead intended to focus on the features we thought may cause issues with the Mobile IP protocol.

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

I agree with you. Would adding the following sentence capture your comment? 
"The issues described above result from the fact that the MN is behind the firewall. Consequently, the MNs communication capability with other nodes is affected by the firewall rules."

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

Yes. As you pointed out, many firewalls already share state (e.g. firewall clusters dealing with asymmetric routes). In such cases, Mobile IP does not create new issues. However I was thinking that when firewalls share the states, they all have to store the same information. When considering large networks, one firewall may not be enough to support all the users. Instead we may need several of them. 

When a user moves between areas served by different firewalls which do not share states, we may have the issues described in the document. Would you agree? 

I will update the document adding the current state of the art you highlighted, and clarifying scenarios when mobility may present new issues. 

> 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 with you. This would work well if the firewall can be configured with the HA of the MN. However when the MN is roaming to a visited network, it may be more difficult to configure the firewall(s) protecting the visited network with the MN's HA. What do you think?
I guess you are moving to the solution space :)

[..]
> installation and configuration mistakes, and should maybe be labelled as

I agree with you. I was just afraid that we may start discussing solutions but we can add few sentences to highlight these differences. We could explain in the conclusion that "Some of the issues described in this document may require changes to firewalls or to the protocols. Others may only require the appropriate rules and configuration to be in place." 

> ESP is in particular recommended for the HoT and HoTI messages between HA

I agree with your comment and analysis. As you pointed out, AH is permitted in the MIPv6 spec., however it seems that the recommendation for ESP was stronger. For this reason, we focused on ESP.

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

Thank you for pointing this out. We will address that as you suggested.

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

Yes, we will move that section in section 5.1

> 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 is a good point. I agree this may be misleading.

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

Thank you.

> I don't see how this differs from Section 5.1, and don't see that it

The issues are similar as you pointed out. However the firewall in section 5.1 is the one protecting the MN (e.g. FW in the visited network) while the firewall in section 5.3 is the one protecting the HA. 

I hope this clarifies the intentions. However I agree that the current text can be confusing. 

Therefore, at the beginning of section 5.3, we will sub /Let's consider a MN moving into a network protected by firewall(s). The following issues may exist:/ with /In the scenarios where the Home Agent is in a network protected by firewall(s), the following issues may exist:/  

and in issue 1, we will sub /If the firewall(s) block ESP traffic/ by /If the firewall(s) protecting the Home Agent block ESP traffic/ 

Would this be clearer?

Franck