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

[Suresh Krishnan <suresh.krishnan at ericsson.com>]

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

Ivancic, William D. (GRC-RCN0) wrote:
> 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."

OK. I will make this change.

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

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

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

OK. I will add the figures.

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

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

_______________________________________________
MEXT mailing list
MEXT at ietf.org
http://www.ietf.org/mailman/listinfo/mext