Subject: AW: [Mip6] [issue24] Mobile IPv6 and Firewalls: Problem statement

From: "Tschofenig, Hannes" <[email-masked]>
Date: Tue, 6 Sep 2005 09:51:26 +0200

hi qiu, 

again a few comments inline:

> Hi, Hannes
> 
> My 2 cents are below.
> 
> ----- Original Message ----- 
> From: "Tschofenig, Hannes" [email-masked]
> 
> >hi all,
> >
> >browsing through your draft i got the impression that you do not talk
> >about firewalls in transit networks either.
> >i understood spencer in such a way that he pointed to 
> firewalls that are
> >between the home, visited, and correspondent networks.
> 
> If I'm not wrong and HMIP is accepted, could we think HMIP is 
> the transit 
> network between home/correspondent network and mobile nodes 
> because MN 
> anchors to a AR that is a subnet under MAP?

my understanding a transit network is a bit different. maybe we should
just ask spencer what he means by a 'transit network' but the map is
quite likely in the access network.

> 
> >a few questions arise:
> >- is the treatment of firewalls in a transit networks (not 
> in the home,
> >visited or cn's network) somewhat special (and does it raise 
> additional
> >requirements)?
> 
> Yes, I am sure somewhat special process is need. The main 
> reason is that the 
> source and destination addresses of packets are variers.  How 
> to config the 
> firewall rules or how to identify a packet?

but that's no different from the treatment of other firewalls in this
context.  
our answer to the need to change packet filters at firewalls is to use a
signaling protocol. 
see
http://www.tschofenig.com/drafts/draft-thiruvengadam-nsis-mip6-fw-02.txt

> 
> >- are firewalls in a transit networks stateful packet filtering
> >firewalls?
> 
> Yes. I think so because stateful packet filtering firewalls 
> is the most 
> popular, and the most  important,  it is deploied in IP level.

it is popular in access networks but these boxes keep per-flow state. 
typically people try to avoid putting devices that keep per-flow state
into networks other than access networks (e.g., core networks)

> 
> >- are additional aspects with firewalls in transit networks 
> specific to
> >a solution or generic.
> 
> come back to the first question.

i guess we will only make progress if spencer tells us what he means by
transit network. 
there are probably other things to discuss that are related to the
solution approaches. however, i think his comment was focused on the
problem statement. maybe we need to address these aspects first before
we get lost somewhere in the details of a particular solution.  

ciao
hannes

> 
> Regards
> Qiu Ying
> 
> 
> 
> > Hi, Spencer
> >
> > Your comments points out the important issues and
> > consideration on the
> > mobile firewall environment.
> >
> > >The stated goal for this document is to enable further 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,
> >
> > Yes, it is true. The draft of mobile firewall
> > (http://www.ietf.org/internet-drafts/draft-qiu-mip6-mobile-fir
> > ewall-01.txt)
> > is one of the thoughts in transit networks between the home,
> > visited, and
> > correspondent networks. The draft discusses a scheme how a
> > administrator (in
> > home) dynamically monitors or controls the communication of
> > roaming mobile
> > nodes (sub-network in visited domain) with the correspondent nodes.
> >
> > The concept of mobile firewall is: when a mobile node (MN)
> > roams into a
> > foreign network managed by a mobility anchor point (MAP), the
> > home agent
> > (HA) will authorize the MAP to serve as a security proxy. 
> The HA will
> > negotiate with the MAP on the security association and then
> > transfer to the
> > MAP the defined security rules that will be applied on all
> > communications to
> > the MN. According to HMIPv6 protocol, all packets to MN will
> > go through MAP.
> > Therefore, the MAP has the ability of filtering packets. The
> > MAP could also
> > send the MN's traffic logs to the HA. The MN's administrator could
> > dynamically monitor the MN's activities by retrieving the
> > MN's traffic logs
> > through the HA. If necessary, the MN's administrator could 
> update the
> > security rules so that the MN's activities could be
> > controlled dynamically.
> > All the operations are transparent to the MN, and the MN will
> > be served in
> > the way specified by its administrator no matter where it roams.
> >
> > This scheme meets the scenario described in section 5.1 of
> > draft-ietf-mip6-firewall.
> >
> >
> > >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.
> >
> > We are trying to make some contribution on this issue. In the
> > first phase,
> > we are developing a practice on said scheme.
> >
> > Regards and Thanks
> > Qiu Ying
> >
> >
> > > Date: Thu, 01 Sep 2005 20:23:42 +0000
> > > From: admin <[email-masked]>
> > > Subject: [Mip6] [issue24] Mobile IPv6 and Firewalls:
> > Problem statement
> > > To: [email-masked]
> > > Message-ID: <[email-masked]>
> > > Content-Type: text/plain; charset=utf-8
> > >
> > >
> > > New submission from admin <[email-masked]>:
> > >
> > > Review comments by Spencer Dawkins (Gen-ART)
> > >
> > > 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
> > >
> > > ----------
> > > category: Editorial
> > > draft: draft-ietf-mip6-firewalls
> > > messages: 90
> > > nosy: admin
> > > priority: Should fix
> > > status: No discussion
> > > title: Mobile IPv6 and Firewalls: Problem statement
> > >
> >
> >
> >
> >
> >
> > _______________________________________________
> > Mip6 mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/mip6
> > 
> 
> 

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

---

From: suraj <[email-masked]>
Date: Fri, 09 Sep 2005 17:33:43 +0530

Dear all,

I have a doubt about why the Change in Registration Type is disallowed for
Binding updates at the correspondent node.

RFC 3775 states:
   If a binding already exists for the given home address and the home
   registration flag has a different value than the Home Registration
   (H) bit in the Binding Update, then the receiving node MUST send back
   a Binding Acknowledgement with status code 139 (registration type
   change disallowed).  The home registration flag stored in the Binding
   Cache entry MUST NOT be changed.

A case can exist where a prospective HA2 is currently acting as a CN (say
when another HA1 in the network is currently serving as Home agent for the
mobile node).
	
  	   HA2(prospective)       HA1  
	  	  |			  |
--Home link---------------------------------------

If the mobile node is switched OFF and ON, it can the next time try the
prospective HA2 for registration, which will fail till the CN binding entry
times out.

Why is this allowed? We can as well allow the CN binding to be replaced when
a Home Reg request is received (more so of we get it through IPSec). This is
more critical when the first HA (HA1) is out of service because of some
reason, thus leading to the MN not being serviced at all for some time.

Is there a specific reason for blocking such Registration type changes?
Maybe this scenario was discussed in the list before.

Please let me know.

Thanks and Regards,
Suraj.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Fri, 09 Sep 2005 15:57:15 +0300

Hello Suraj,

I don't remember a lot of specific discussion, and likely as not
the prohibition was a matter of convenience in the specification.
In general it is easier to prohibit some feature that might be
unsafe, especially when no one is asking for that feature.

In the case you describe, it seems to me that the mobile device
ought to deregister its old binding before powering down.
If graceful deregistration isn't possible, then it should be done
when the device recognizes that it has failed to do so.  If it's
on its home link, this should be possible.  Actually accepting
the registration might be unwise, if the binding to the CN were
secured by a key derived from return routability.  Acting as
a home agent might require a stronger security association
than acting as a correspondent node.

But this is all from memory without verifying the relevant
parts of RFC 3775.

Regards,
Charlie P.

---

From: Jari Arkko <[email-masked]>
Date: Fri, 09 Sep 2005 16:17:40 +0300

I believe this was in the spec because it was thought that
these situations would mainly be the result of an error.
One problem that could occur is that if HA1 still thinks
its the home agent, then HA2 wouldn't be able to run
DAD.

But I recognize the possibility that in a multi-HA situation
you might dynamically become a HA from a CN, or vice versa.
My advice is to cleanly de-register before doing such a change; this
at least makes everything very explicit.

--Jari

Charles E. Perkins wrote:

>>         HA2(prospective)       HA1              |              |