Adoption of MIPv6 Operation with Firewalls draft

[Julien Laganier-2]

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
MEXT@...
https://www.ietf.org/mailman/listinfo/mext

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: mext@...
> Subject: [MEXT] Adoption of MIPv6 Operation with Firewalls draft
>
> 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
MEXT@...
https://www.ietf.org/mailman/listinfo/mext

[Suresh Krishnan (QB/EMC)]

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

Pasi.Eronen@... wrote:
> 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.

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
> return routability messages are not encrypted, something that RFC 3776
> 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
> 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.

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
_______________________________________________
MEXT mailing list
MEXT@...
https://www.ietf.org/mailman/listinfo/mext

[Vijay Devarapalli-3]

Hi Suresh,

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

Vijay

> -----Original Message-----
> From: mext-bounces@... [mailto:mext-bounces@...] On
> Behalf Of Suresh Krishnan
> Sent: Thursday, September 04, 2008 11:59 AM
> To: Pasi.Eronen@...
> Cc: julien.laganier.ietf@...; mext@...
> Subject: Re: [MEXT] Adoption of MIPv6 Operation with Firewalls draft
>
> Hi Pasi,
>    Thanks for reviewing the draft and for the comments.
>
> Pasi.Eronen@... wrote:
> > 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.
>
> 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
> > return routability messages are not encrypted, something
> that RFC 3776
> > 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
> > 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.
>
> 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
> _______________________________________________
> MEXT mailing list
> MEXT@...
> https://www.ietf.org/mailman/listinfo/mext
>

_______________________________________________
MEXT mailing list
MEXT@...
https://www.ietf.org/mailman/listinfo/mext