Re: [Mip6] IETF69: MIP6 WG meeting minutes -- Firewall Recommendations for MIPv6

["QIU Ying" <[e-mail]>]

Hi,



Regarding the draft of "Firewall Recommendations for MIPv6", my 2 cents 
below.



> 6. Firewall Recommendations for MIPv6
>   I-D: draft-krishnan-mip6-firewall-01            15 min
>   Suresh Krishnan
> --------------------------------------
> * presentation:
> - different scenario: firewall protecting HA, MN, CN, respectively
> - recommends which kind of traffic should not be blocked by firewalls
> - Adopt as WG draft?
>
> * discussion
> - hesham: just to clarify, only some firewalls in enterprise networks
> block ipsec. Not in public networks
> - frank: your solution makes network less safe (let all IPsec traffic
> to HA through).
>    - Suresh: but this is the HA service, you have to let this
>    traffic through



Frankly, in practice realm, home agents are very special nodes: 1) only few 
nodes are charged as home agents within a networks. 2) Home agent is 
normally functioned as a server or a stationary machine at least, so it is 
strong enough to protect itself (e.g. Jari mentioned access mechanisms) and 
not have to rely on the protection of firewall.



A firewall that opens few channels for some specified robust nodes do not 
means to weaken the strength of network security.



But in order to prevent the flood attacks, the firewall can constrain the 
throughput of these channels.


> - Alex: some operators don't want to allow RO due to security weaknessses
>    - Suresh: that's why we separated rules for RO and for non-RO



No matter RO or non RO, the issue of IPsec packets through a firewall can 
not avoid due to home binding update.



Regards

Qiu Ying




> Date: Fri, 24 Aug 2007 17:28:24 -0500
> From: Basavaraj Patil <[e-mail]>
> Subject: [Mip6] IETF69: MIP6 WG meeting minutes
> To: Mobile IPv6 Mailing List <[e-mail]>
> Message-ID: <[e-mail]>
> Content-Type: text/plain; charset="ISO-8859-1"
>
>
> Minutes of:
> Mobility for IPv6 (mip6) WG
> At: IETF69 (Chicago)
> TUESDAY, July 24, 2007 from 1520-1720
>
> Chairs: Basavaraj Patil <[e-mail]>
>    Gopal Dommety <[e-mail]>
>
> Credit for these minutes:
>
> 1. Kilian Weniger ([e-mail])
>
> 2. Jabber scribe: T.J Kniveton ([e-mail])
>
> ====================================================
>
>
> 1. Agenda review, Blue sheets and volunteers for
>   notes and Jabber                                               5 Mins
>
> 2. WG status and I-Ds update                                 10 Mins
> ----------------------
> - Raj announces public Home Agent Service
>  Refer to slides for details of HA service.
>
> - Status of MIP6 WG
>    - last meeting as MIP6 WG.
>
> - Status of MEXT (jari)
>    - charter approved at IESG
>    - remaining thing is to select chairs
>
> - Document status
>    - RFCs published
>        - draft-ietf-mip6-ikev2-ipsec (prop standard)
>        - draft-ietf-mip6-privacy-ps (informational)
>    - RFC ed queue
>        - draft-ietf-mip6-dsmip-problem (informational)
>    - IESG review
>        - draft-ietf-mip6-bootstrapping-split (prop standard)
>    - AD review
>        - draft-ietf-mip6-cn-ipsec (experiremtal)
>        - draft-ietf-mip6-bootstrapping-integrated-dhc (proposed standard)
>            - waiting for draft-hiopt
>    - new WG docs
>        - haley-mip6-mh-signaling (
>    - completed last call
>        - whyauthdataoption
>        - aaa-ha-goals
>        - hiopt
>        - vsm
>        - experimental-messages
>    - ready for WGLC
>        - rfc4285bis
>        - hareliability
>        - nemo-v4traversal
>    - misc
>        - draft-ietf-nip6-radius (waiting for AAA-goals ID complÈtion)
>
> * discussion
> - Vijay: aaa-ha-goals document is far from complete. Basic stuff is 
> missing.
> - Raj: this doc is expired. Please send comments to ml.
>
> 3. Mobile IPv6 bootstrapping in split scenario
>   I-D: draft-ietf-mip6-bootstrapping-split-06           15 Mins
>   Vijay Devarapalli
> -----------------------------------------
> * presentation
> - changes since last version:
>    - anycast-based HA assignment removed during security AD
>   review because it may be applied elsewhere too (not only MIPv6)
>    - use of PKI/certificates was underspecified
>    - what to do if HA does not respond to IKE_SA_INIT was underspecified
>    - format of MIP6_HOME_PREFIX attribute had mistakes
>    - clarifications on home address authz
>
> * discussion
> - jari: no DISCUSSes anymore. Doc is ready to progress
>
>
> 4. DHCP Option for Home Information Discovery in MIPv6
>   I-D: draft-ietf-mip6-hiopt-05.txt            10 Mins
>   Heejin Jang
> --------------------------------------
> * presentation
> - changes since last version:
>    - no HoA assignment support anymore
>    - clarification of meaning of id-types
>    - clarification of use of multiple HN identifier options
>    - new fields in HN information option
>    - deleted MN-NAI option in relay-forward msg
>
> * discussion
> - none
>
> 5. Binding Revocation for IPv6 Mobility
>   I-D: draft-muhanna-mip6-binding-revocation-01.txt     15 min
>   Ahmad Muhanna
> -------------------------------------
> * presentation
> - motivation for binding revocation
> - binding revocation msg format
> - proposes to adopt as WG item and change charter
>
> * discussion
> - Greg: Why is this better than sending BA with lifetime 0?
>    - Sri: you can't revoke all binding with single BA msg
>    - Greg: don't see how this can be secure
>    - Ahmad: in case of PMIP, there is no per-MN SA
> - Vijay: Why revoke a specific CoA in case of monami6
>    - Sri: just to revoke one particular flow
> - Raj: You said motivation is maintenance etc. Now you say its for
> monami6 to selective revoke flows. Those are other, more complicated
> scenarios
> - Hesham: Not sure if this works, since MN can switch flow to other
> BIDs. So this flow is not stopped. To revoke all flows, you don'T need
> BID
> - Kuntal: Example were it makes sense to revoke single binding is,
> e.g., in IMS scenarios
> - Hesham: Clarification: I think there are many ways to revoke
> particular flows. Don't think this should be done by MIP HA
> - Vijay: we just need simple revocation mechanism based on MN
> identifier or HoA. Not more (not revoke specific flows)
>    - Raj: agree, that would be too complex
> - alex: supports use of binding refresh request
> - alex: another technical comment to be sent on the mailing list
> - alex: proposes another code, that tells HA to keep sessions up when
> MN wants that
>    - Raj: in such case MN should go find another HA
> - Kuntal: Important use cases are handover and clear-up of ressources
> on old gateway. Maintenance is rare use case
> - Ruji: We can treat every binding of multiple binding as single
> binding. Support revocation of one of multiple bindings of a MN
> - ?: thinks this draft is useful
> - TJ: this should be kept simple.
>
> - Greg: binding revocation must be sent by entity that MN has binding with
>
> - chairs: How many of WG think that we should do binding revocation
>    - extension for MIP6?
>    - yes: 8+
>    - no: 0
> - chairs:
>    - Let's have discussion on ml and then decide about adoption
>      of draft as WG doc
>
>
>
> 6. Firewall Recommendations for MIPv6
>   I-D: draft-krishnan-mip6-firewall-01            15 min
>   Suresh Krishnan
> --------------------------------------
> * presentation:
> - different scenario: firewall protecting HA, MN, CN, respectively
> - recommends which kind of traffic should not be blocked by firewalls
> - Adopt as WG draft?
>
> * discussion
> - hesham: just to clarify, only some firewalls in enterprise networks
> block ipsec. Not in public networks
> - frank: your solution makes network less safe (let all IPsec traffic
> to HA through).
>    - Suresh: but this is the HA service, you have to let this
>    traffic through
> - Alex: some operators don't want to allow RO due to security weaknessses
>    - Suresh: that's why we separated rules for RO and for non-RO
>
> - chairs: status of design team? Are they finished?
>    - suresh: there is some stuff more forward looking, e.g.,
>    - talking to firewall. This draft is the first/essential step
> - Jari: the future stuff sounds a bit dangerous. Why not rely on
>    - access mechanisms? Why need something specific for MIP6.
>    - suresh: Hannes wants to extend existing ipv6 protocol for mip6
>    - jari: this makes more sense
>
> - jari: so question is whether we do the BCP for the firewall rules
>  here or leave it for MEXT? You can work on that under current
>  charter
>
>
> 7. Mobile IPv6 Extension for Configuration Options
>   I-D: draft-bharatia-mip6-gen-ext-01.txt           15 min
>   Kuntal Chowdhury
> -------------------------------------
> * presentation:
> - motivation: get configuration from home network
> - idea: MN includes option in MIP6 BU to request list of host config
>   options. BA contains config info. Config information format is
>   re-used from DHCP
>
> * discussion
> - Frank: Why use MN-HA interaction? BU is not very flexible. Why not
> use AAA? Tomorrow we have another service, then we again need to
> change specification.
>    - Kuntal: if new service shall be discovered, then we just
>    need to define another option code. AAA doesn't work, since MN
>    does not talk to AAA server
> - Ruji: 1. on home link, this mechanism doesn't work. 2. in PMIP,
> better to decouple binding signaling and address assignment. You an
> use DHCP
> - Greg: we have SLP, DHCP, MIH, Router discovery. So why do we need to
> another discovery protocol, which we have to secure etc.
>    - Raj: we should discuss this on the ml
> - hesham: I agree with greg. Same discussion about that for mip4 some
> years ago and IESG was against.
>    - Kuntal: this work is currently done in mip4
> - kent: sees difference between mip4 and mip6 case, since we have a
> bootstrapping mechanism in mip6. Why not use it?
>    - Kuntal: you could add AAA attributes + DHCP relay
> - Jari: we don't do anything here before we know what happens to the
> mip4 document
>    - Henrik: agree. we can't just assume that mip4 and mip6 case
>    are the same. Why not just use DHCP on link?
>
> 8. IP Tunneling Optimization in a Mobile Environment
>   I-D: draft-haddad-mip6-tunneling-optimization-01    10 min
>   Wassim Haddad
> ------------------------------------
> * presentation
> - motivation: reduce tunneling overhead
> - idea: removing inner tunnel header in MIP, PMIP,...
> - PAD translator, which is XOR of inner and outer header
> - PAD translator is updated by HA when receiving BU
>
> * discussion
> - chairs: There is an IPR disclosure on this draft
> - sri: is it compatible with existing header compression like rohc?
>    - suresh: yes, can use Rohc on outer header
> - alex: it can work. Good to mention that it has IPR. rohc is much
> more powerful.
>    - suresh: rohc has different stands than this one
> - alex: this is no longer MIP6. So is this an alternative to MIPv6?
>    - suresh: this could be done below MIPv6
> - Hesham: this is fantastic. Good idea. And IPR is defensive, right
>    - suresh: yes
> - greg: this is good. The killer application is maintaining 1500bytes
> MTU. You can't do that with rohc. But may not work immediately with
> all CN addresses
> - Henrik: should define term BT. First though on Bittorrent, bluetooth ;)
>
> 9. Interfacing between IKEv2/IPsec & MIPv6 by simple PF_KEY extensions
>   I-D: draft-qi-mip6-ikev2-interfacing-00.txt        5 Min
>   Yang Peng
> ---------------------------------
> * presentation
> - provide interface between IKEv2 and MIP6
>
> * discussion
> - chairs: this has to be discussed based on the MEXT charter
>
>
> 10. Next Steps        Chairs                         10 Mins
> ----------------------------
> - upcoming WGLCs and submissions to IESG
>
>
>
>
>
> ------------------------------
>
> _______________________________________________
> Mip6 mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/mip6
>
>
> End of Mip6 Digest, Vol 40, Issue 15
> ************************************ 


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

_______________________________________________
Mip6 mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/mip6