Subject: [MEXT] firewall-vendor and firewall-admin review - editorial

From: "Ivancic, William D. (GRC-RCN0)" <[email-masked]>
Date: Fri, 15 Feb 2008 15:18:50 -0600

I was asked to review both 

Guidelines for firewall vendors regarding MIPv6 traffic
draft-krishnan-mip6-firewall-vendor-02

and 

Guidelines for firewall administrators regarding MIPv6 traffic
draft-krishnan-mip6-firewall-admin-02

I read the earlier versions and now the most recent versions.  I read
them over a few times and do not have much to add to those documents
except for some minor editorial suggestions.  I believe most details are
covered regarding how to allow MIP to work relative to communicating
through a firewalled network.

I will  submit a second email on operations.  This only covers editorial
comments except for recommendation 4.

Recommendation #1
=================

In both document in the introduction, section 2 it states:

"Since firewalls are not aware of MIPv6 protocol details, they will
probably interfere with the smooth operation of the protocol."

To me, there is no doubt or probability.  Firewall WILL break MIPv6 (and
MIPv4 and NEMO) unless steps are taken.  Thus, I suggest changing the
wording to:

"Firewalls will interfere with the smooth operation of the MIPv6
protocol unless specific steps are taken to allow Mobile IPv6 signaling
and data messages to pass through the firewall."

Recommendation #2
===================
The people on the MEXT or MIP6 mail lists are probably familiar with the
MIP abbreviations - although even I have to sometimes go back and look
up what HoTI or CoT are.   A firewall vendor or administrator is likely
to have little familiarity with those terms.     For example in the
firewall-vendor draft section 4.

"4.  Allowing signaling response packets

   The MIPv6 signaling messages are usually performed as a request-
   response pair. ..... There are 3 message pairs that are
   of importance to MIPv6 signaling.  They are the BU/BA, HoTI/HoT and
   CoTI/CoT pairs.  ...."
   
Thus, I recommend that an abbreviations list be provided as is done in
section 3 of RFC4487 - see below.  Also, if there is a MIPv6 or MIP
document that defines mobile ip terms, it would be good to reference
such a document.

From RFC4487 section 3.
3.  Abbreviations

   This document uses the following abbreviations:

   o  CN: Correspondent Node

   o  CoA: Care of Address

   o  CoTI: Care of Test Init

   o  HA: Home Agent

   o  HoA: Home Address

   o  HoTI: Home Test Init

   o  HoT: Home Test

   o  MN: Mobile Node

   o  RO: Route Optimization

   o  RRT: Return Routability Test

Recommendation #3
=======================
A picture is worth a 1000s words.  I probably would be useful to
duplicate the graphics in RFC4887 - at least in the firewall-admin
document.  If one is not familiar with MIPv6 operations, those pictures
may help quite a bit.  

From RFC4887

     +----------------+       +----+
     |                |       | HA |
     |                |       +----+
     |                |      Home Agent
     |  +---+      +----+      of A               +---+
     |  | A |      | FW |                         | B |
     |  +---+      +----+                         +---+
     |Internal        |                         External
     |   MN           |                           Node
     |                |
     +----------------+
     Network protected

   Figure 1: Issues between MIP6 and firewalls when MN is in a network
             protected by firewalls
             
Recommendation/Question #4
===========================
Regarding the firewall-vendor document.

In today's MIP deployments (v6, v4, NEMO), when MIP signaling is blocked
by a firewall, does that firewall return any type of message to allow
one to debug the system?  Quite a few years ago when I did NEMO IPv4
with a T-Mobile network we were operating fine one day and the next day
everything broke.  It turned out T-Mobile started administratively
filtering on what we considered an open network.  At least we received
"administratively filtered" messages and could track down the problem.
http://roland.grc.nasa.gov/~ivancic/t-mobile/administrative_filtering.pd
f

My recommendation is that vendors should provide some type of uniform
signaling to indicate that MIP signaling was administratively filtered.
Perhaps some new ICMP message or at least a recommendation of which to
send.

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

---

From: Suresh Krishnan <[email-masked]>
Date: Fri, 15 Feb 2008 16:36:46 -0500

Hi William,
   Thanks for the comments. Please find my responses inline

> and data messages to pass through the firewall."

OK. I will make this change.

> Recommendation #2

OK. I will do this. It sounds like a good idea.

> Recommendation #3

OK. I will add the figures.

> Recommendation/Question #4

ICMPv6 Type 1 (Destination unreachable) message with code 1 - 
communication with destination administratively prohibited seems like a 
good fit for this, but I am open to the idea of a new type/code

Thanks
Suresh

---

From: RYUJI WAKIKAWA <[email-masked]>
Date: Mon, 18 Feb 2008 16:44:47 +0900

Hi Suresh,

> good fit for this, but I am open to the idea of a new type/code

Any notification is useful to know the firewall condition for the  
debugging purpose.
But how can the MIP6 stack process these ICMP packets?
Are you going to specify the new MN's behavior here ?

regards,
ryuji

---

From: "Ivancic, William D. (GRC-RCN0)" <[email-masked]>
Date: Tue, 19 Feb 2008 07:39:16 -0600

Comments In line:

> >> Perhaps some new ICMP message or at least a recommendation 
> of which 
> >> to send.
> >
> > communication with destination administratively prohibited 
> seems like 
> > a good fit for this, but I am open to the idea of a new type/code
> 
> Any notification is useful to know the firewall condition for 
> the debugging purpose.

Ruuji,

I don't think it is necessary to specify new MN behaviour.  It would
just be nice BCP to have a consistant ICMP message - probably not even a
new one - so that  if/when things break it is a little easier to track
down.  The suggested ICMPv6 Type 1 reply seems reasonable to me.

/will