Re: [MEXT] firewall docs review

Hi, Ryuji

On February 19, 2008 11:00 AM, RYUJI WAKIKAWA wrote

> Hi, Qiu
>
> On 2008/02/18, at 19:57, QIU Ying wrote:
>
>> Hi, Ryuji
>>
>> Thanks for your comments. My response is inline.
>>
>> ----- Original Message ----- "RYUJI WAKIKAWA" wrote
>>
>>
>>> Hi Suresh and authors,
>>>
>>> I was asked to review draft-krishnan-mip6-firewall-admin-02 and
>>> draft-krishnan-mip6-firewall-vendor-02.
>>>
>>> - Can current filtering mechanism check the IP options field?!
>>
>> No. Current firewall filter does not support to check the IP options 
>> field.
>
> It's up to implementation, isn't it?
> I can easily setup the firewall with PC which can check the IP  options...
> Which firewall products are you assuming?
>
> Are there substantial reasons to say NO here?

Do you mean to use the filter of routing header? If I am not wrong, the 
current ip6tables (e.g. in Linux) only support route header in  type 0. But 
the formats between type 0 and type 2 route header are a bit of difference. 
It's why we should suggest the modification in vendor-draft instead of the 
admin-draft. Anyway, if most current firewalls already implement this 
feature, we should mention it in admin-draft

>
>>
>>>  If yes, the document should mention which IP options are appeared
>>> for which packets.
>>>  An example is DST Opt for BU and RTHDR for BA.
>>>  Otherwise, the operator might just block all the packets having
>>> RTHDR option regardless of BA.
>>>
>>> For example, in section 3.1 of draft-admin ,
>>>     Destination Address: Address of HA
>>>                                                   <-- adding  Dest
>>> option (HoA option)?
>>>     Next Header: 50 (ESP)
>>>     Mobility Header Type: 5 (BU)
>>
>> For draft-admin, which purpose is BCP, so we could not solicit the 
>> function here. But we could provide the filter in draft-vender.
>>
>>>
>>> - missing authentication option and DSMIP support?
>>>   DSMIP will introduce much complexity to firewall setup.
>>
>> The target of these two draft is to make MIP6 signalling pass  through 
>> the firewalls. So, in my opinion, the issue of  authentication and DSMIP 
>> might be out of the scope.
>
> DSMIP seems to be adapted to many deployment case.
> why not:-)

In my opinion, the dual stack issues are more focused on the process on the 
two-peers of communication. A firewall, which is located on middle-way, is 
just take care the IP headers. A traffic packet is either IPv4 packet or 
IPv6 packet no matter if it includes dual stock information. So I do not 
think it was necessary to require a firewall to detect the dual stack 
information. These 2 drafts are about the modification of IPv6 firewall. If 
IPv4 issues should be considered too, we could raise other drafts

Regards
Qiu Ying

>
> ryuji
>
>>>
>>> - RO is optional in the RFC3775. I am not sure you can treat
>>>  RO signaling as same as the BU/BA for firewall filters setup.
>>>   It might be good if you provide the minimum set of rules (BU/BA
>>> only)
>>>  and the full set of rules (All MH signaling).
>>
>> Good comments.
>>
>> Regards and Thanks
>> Qiu Ying
>>
>>
>>>
>>> - why are these two separate documents?
>>>
>>> regards,
>>> ryuji
>>> _______________________________________________
>>> MEXT mailing list
>>> MEXT@ietf.org
>>> http://www.ietf.org/mailman/listinfo/mext

------------ Institute For Infocomm Research - Disclaimer -------------This email is confidential and may be privileged.  If you are not the intended recipient, please delete it and notify us immediately. Please do not copy or use it for any purpose, or disclose its contents to any other person. Thank you.--------------------------------------------------------
_______________________________________________
MEXT mailing list
MEXT@ietf.org
http://www.ietf.org/mailman/listinfo/mext