Subject: [MEXT] Adoption of MIPv6 Operation with Firewalls draft

From: Julien Laganier <[email-masked]>
Date: Thu, 4 Sep 2008 11:09:43 +0200

Folks,

The MEXT WG charter has a "Mobile IPv6 Operation with Firewalls" 
deliverable, but the WG doesn't have a corresponding draft(s). There 
are two individual submissions that could be used as basis for the 
deliverable:

<http://tools.ietf.org/id/draft-krishnan-mip6-firewall-admin-04.txt>
<http://tools.ietf.org/id/draft-krishnan-mip6-firewall-vendor-04.txt>

Hereby we'd like to ask WG participants whether or not we should adopt 
the two drafts above as MEXT WG drafts for the "Mobile IPv6 Operation 
with Firewalls" deliverable.

Please state your opinion on the above before Sep 18th.

--julien & marcelo, MEXT chairs
_______________________________________________
MEXT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mext

---

From: <[email-masked]>
Date: Thu, 4 Sep 2008 13:26:55 +0300

BTW, the drafts seem to assume that the MIPv6 messages are not encrypted
(i.e. either ESP with NULL encryption or RFC 4285 is used), so the
firewall can inspect e.g. the MH Type field. (It's even assumed that
return routability messages are not encrypted, something that RFC 3776
or 4877 do not permit.) They also require Mobile IPv6 specific deep
packet inspection. I guess these assumptions are intentional (but at
least the first one isn't very clearly mentioned in the specs), but
they do limit the applicability somewhat.

Best regards,
Pasi

> -----Original Message-----
> From: Julien Laganier
> Sent: 04 September, 2008 12:10
> To: [email-masked]
> Subject: [MEXT] Adoption of MIPv6 Operation with Firewalls draft
> 
> Folks,
>

---

From: Suresh Krishnan <[email-masked]>
Date: Thu, 04 Sep 2008 14:58:53 -0400

Hi Pasi,
   Thanks for reviewing the draft and for the comments.

[email-masked] wrote:
> firewall can inspect e.g. the MH Type field. 

You are right. We did make this unstated assumption. The first version 
of the draft 00 assumed encrypted ESP was the norm and that packets were 
not inspectable. But RFC3775 was not mandating encryption for most of 
the mobility signaling (BU,BA,HoTI,CoTI,CoT) while mandating encryption 
only for HOT messages. So we thought that detailing out the MH types 
could be helpful. We also added the following (weasel!) text to the 
Security Considerations

"Since some
  of this traffic is encrypted it is not possible for firewalls to
  discern whether it is safe or not.  This document recommends a
  liberal setting so that all legitimate traffic can pass."

> (It's even assumed that
> or 4877 do not permit.) 

Encryption is required only for HoT messages. All other RR messages do 
not have to be encrypted.

> They also require Mobile IPv6 specific deep

True. We would appreciate any suggestions on how you would like us to 
handle ESP encrypted packets in this document. Is it sufficient to add 
the blanket filter specs for ESP packets or is there anything more we 
can do?

Thanks
Suresh

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Thu, 4 Sep 2008 18:16:21 -0400

Hi Suresh,

The same ESP tunnel SA would be used to protect both HoTI and HoT. So,
both will be encrypted.

Vijay 

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Suresh Krishnan
> Sent: Thursday, September 04, 2008 11:59 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: Re: [MEXT] Adoption of MIPv6 Operation with Firewalls draft
> 
> Hi Pasi,