MIP4 WG Minutes (Thursday, March 10, 2005, 1645-1745)
MIP4 WG Minutes (Thursday, March 10, 2005,
1645-1745)
Minute takers: Espen Klovning, Jayshree Bharatia, Will Ivancic
Henrik: Pete McCann could not be here so I am on my own here.
Henrik had not received slides from Vikas Goel and therefore
dropped his presentation of draft-goel-mip4-encapext-00.txt
Vikas asked whether he could to add the presentation to the
agenda. Henrik allocated a slot at the end of the agenda.
draft-ietf-mip4-rfc3344bis-01
Slides: http://tools.ietf.org/wg/mip4/ietf/62/fa-ha-sa-selectors.pdf
This issue revolves around what selectors (e.g., Reg. Request CoA
and HA address) should be used to select the SA (security association)
used to calculate FA-HA Authorization-enabling extensions.
Issue: Selector for the HA-FA Security Association.
- When the MN sends a de-register request to a foreign agent
with the intention of de-registering its earlier binding it had with a
different foreign agent, the behavior of FA in RFC3344 is to reject
such request with invalid care-of address error. However, the HA
considerations allows such requests. The scenario is not handled
consistently at both HA and FA ends.
- Also, if the foreign agent is allowed to forward such
requests, there is no explanation as how the home agent should locate
the security associations for that FA and validate the FHAE.
- This issue was also discussed in IETF-61. The following are
the selector fields: - Source IP address - Destination IP address -
Care-of address - Home address - Lifetime field (or the bit which says
that it is zero or not) - The D bit (to determine whether coa is
co-located).
It was mentioned that CoA and HoA usage may be problematic
because there will not be correct security association in those cases.
Comments:
Kent Leung:
Agreement was that we are not considering NAT scenario
(out of scope for RFC3344). Also, SA (indexed by the source IP address)
would solve the problem. This source address will always be known by
the HA.
- Henrik:
- Referred to as a,d here.
- Kent:
- Agreed to go with that approach. Just gone use IP src to
index cover all the case. It been awhile.
- Henrik:
- It would be nice to find a solution for the non-NAT case. We
will have to revisit NAT case too. We must be aware of that now.
Permitting COA MN to send directly.
- Kent:
- It was brought up but it is breaking some processing rules.
It is the R bit case right. We will not be able to go over this now. We
should start from our email discussion.
- Henrik:
- We have no known starting point.
- Kent:
- We are probably too tired to discuss it
- Charlie:
- I did run out of steam.. We were at equilibrium
...
- Kent:
- I do not mind any good approach. We have not found it yet.
- Henrik:
- What is your view of the status?
- Kent:
- What I stated earlier was the status.
- Henrik:
- We need a known starting point. I had hoped we had come to a
point where we could agree.
- Kent:
- I can summarize how far we have come.
- Resolution:
-
Action item:
Kent to summarize how far this
communication has gone. The working group will consider this as a new
starting point. Note that there was no resolution offered on this
issue. There will be further discussion on the mailing list.
draft-sastry-mip4-string-extension-00.txt
Slides: http://tools.ietf.org/wg/mip4/ietf/62/genericstring.pdf
This document specifies an extension to carry a text string in
the Registration Reply messaged, with the purpose of having the text
string displayed on the Mobile Node user interface.
Alpesh presented the draft that stems from customer requests
during deployment.
- This draft defines a new skippable extension for use by HA and
FA in registration request. Note that both FA and HA can add this
extension in to the same registration request.
- A new subtype defines two values indicating who adds this
extension. If this extension is added by the HA, it must be present
before MHAE.
- In case of authentication failure, error is returned. The text
field of the extension can be displayed on MN's user interface. The MN
may throttle the message.
Comments:
Espen Klovning:
The mechanism is OK but I do not like the reference to
user interface. The MN might not have a user interface. It could write
the string to a log. Tone down the reference to user display. It is up
to the MN to decide what to to with the information.
Avi Lior:
I like the draft. In case of AAA, user doesn't know
the detail. Although it is not clear how to indicate whether the string
should go to the user or not.
Kent:
I agree with Espen. It is up to the MN to decide what
to to with the strings.
Xxx:
This can be appended by both nodes in the same
message. If FA adds this extension, it can't be authenticated (which is
optional).
Henrik:
This is within the scope of this WG but will require a
charter update.
Resolution:
Enough interest (humming) to make this a WG item
- Action:
- Charter update will be proposed by the chair for this work.
draft-leung-mip4-host-config-vse-00.txt
Slides: http://tools.ietf.org/wg/mip4/ietf/62/hostconfig.pdf
This document describes the extensions used to provide the base
host configuration in the Registration Request and Reply messages.
Kent presented:
- The MN needs additional configuration to setup MIP interface.
This is from the deployment perspective. Current host configuration is
insufficient.
- Defines NVSEs in the registration Request used by HA to
include DHCP in response. Host configuration types includes HA prefix,
DHCP server, DNS server, DHCP client ID, default Gateway, DNS suffix
and config URL.
- The informational status is asked at this time by the author.
Again, this will go as vendor specific option.
Action:
It wasn't very clear whether WG should take this
document as a WG item or not. Although 6 people volunteered to support
this draft if it is taken as a WG item.
Henrik:
There are currently 4 proposed solution drafts for
MIPv4/MIPv6 transition. One for MIPv4 and three for MIPv6. The drafts
describes different alternatives. It is not clear where this work
belongs to at this time. Non of the solution are complete. I think we
should start by producing a problem statement.
Show of hands indicated little interest in the WG for taking the
transition issue up as a WG item.
Comments:
Thomas:
Surprised over the lack WG interest. Charter WG to
have clear idea. Current deployments of MIP4 that wants to go to IPv6.
Vijay:
There are two distinct scenarios of interest, One for
a MIPv6 node to reach the IPv6 network over IPv4, and the other for
people who currently have MIPv4 deployed but would like to move to
MIPv6.
Kent:
Too many access network with IPv4. That is the reason
for the interest in MIPv6.
Thomas :
Ok, so the first scenario would fit better in the MIP6
working group.
- Action:
- None
draft-ietf-mip4-reg-tunnel-00.txt
Henrik:
There is a small issue on how to handle AD review
feedback. Charlie?
Charlie:
We will be able to answer all issue that has been raised
by the ADs. We should have a new draft shortly after the beginning of
June.
draft-nakhjiri-radius-mip4-00.txt
Slides: http://tools.ietf.org/wg/mip4/ietf/62/radius_mip4.pdf
This document defines the RADIUS attributes that provide support
for Mobile IPv4 operations such as key management and authentication
services during a mobile node's registration process.
Madjid presented the draft.
- This draft is relevant to MIP-AAA interaction. A receipt of
the registration request results in to the authentication and creation
of new security association. There is no document detailing this
information from the AAA perspective. All current documents are written
w.r.t. MIP. Two cases are considered, co-located and FA-based CoA.
- Can't do Radius extension unless this WG endorse this work.
Hence Liaison is needed from MIP4 to RADEXT WG.
- Want to make sure that MIP functionality is verified by this
working group.
- Comments:
-
Alpesh:
We have due to deployment requirements made vendor
specific solutions that do the same. There is interest for this.
Kent:
There is definitely deployment interest.
Avi Lior:
We have to review the semantics of the attributes.
View whether RADIUS protocol is violated. Perhaps WG item. Primarily,
ask Radius to review it.
Henrik:
When I worked on MIPv4 deployments, we did our own.
Having a standardised set will be good. This will be a WG item for
RADEXT. They need to know how we evaluate this, though.
Thomas:
It defines new attributes. Then the right home is
the RADEXT WG. It does not matter. Both WG must be happy with the
solution.
Alpesh:
We need to think about 3012bis in this. Only MD5 is
supported in 3012bis. RADIUS have limitations. There are no mechanisms
to use HMAC or SHA1, and MD5 is being deprecated in RADIUS group.
Charlie:
This should be standardized in RADEXT working group
similar to what has been done for DIAMETER.
Kent:
Agree with Avi. We have to look at the
semantics of fields. It should be decided by MIP experts. After
consensus we should go through RADEXT WG to get approval.
Action:
Humming indicated that the WG should invest energy in
this document. Although the decision on where it will land as a wg item
is still open.
RFC 3519
Slides: http://tools.ietf.org/wg/mip4/ietf/62/3519-bis.pdf
Experience with RFC 3519 and discussions around rfc3344bis has
brought to light some weaknesses of RFC 3519 which may warrant starting
work on a revision of this. This presentation will give a summary of
these issues.
Sri presented a few issues/problems with RFC3519 that have been
detected during implementation and deployment.
- The motivation for this draft is to present different issues
which are related to RFC3519 and found from the implementation.
- Issue 44: According to RFC3344, the FA is required to send a
registration request with the source address of the outgoing interface.
This conflicts with RFC3519 where the FA is required to set the source
address of the registration request to its CoA.
- Issue 45: HA dependency on the source address for the NAT
detection logic.
- Issue 3(?): Keep-alive message. This has no protection. This
is causes inconvenience.
- Issue 4: Usage of ICMP echo packet format for the keep-alive
message and the associated issue. Protocol package, the context should
be maintained (either MIP subsystem or something else)
- Issue 5: Overloading the MIP port 434 for control and data
messages and the implementation issues. Need to identify whether this
is a data or control packet. This is just a UDP package and goes all
the way to the application layer.
- Issue 6: FA doesn't have any role for request but the reply is
not the same. It may be of different version which may cause problem.
- Comments:
-
Henrik:
I am fine with all the issues except the one where
the port number can be done in kernel. No bis issue. Another protocol.
Alpesh:
The problem with 3519 is that the same channel is
used for both signaling and data
Espen:
This is an router/hardware performance
issue that is less relevant for client implementations.
Action:
Suggest to make 3519bis an WG item. Henrik will serve as
editor and got commitment from 5-6 people to contribute to this draft.
draft-goel-mip4-encapext-00.txt
This drafts describes an extension which allows the Home Agent to
specify, in the Registration Reply, the kind of encapsulation types it
supports.
Vikas presented a draft to address a scalability issue with
tunnel endpoints in the where the HA should force the MN to use a
specific tunnel encapsulation.
Comments:
Espen:
This will not work as long as the M and G bits are not
mandatory in RFC 3344.
Vikas:
You have to set up three tunnels for each HA. It will
not scale.
Kent:
This is not necessary. The RRQ can not indicate more
than one tunneling method.
Espen:
Yes, you can.
Sri:
What is the original intent? There is no way for the
HA to know what to use. Deployment scenario should be well understood.
Xxx:
HA just reacts on what is selected by the MN. But if
it is different from what HA wants, there may be a need of supporting
two encapsulation choices.
Henrik:
Don't see a clear need. This makes sense only if HA
supports either G or M. It doesn't make sense if HA supports both.
Generally clients are not deployed which are incompatible with HA. This
doesn't seem like a real issue since num of choices are few only.
Henrik:
Encapsulation offer goes in a registration request and
the selection of the encapsulation is received in the registration
reply. Hence there may not be any need of having multiple tunnels.
Kent:
The proposed solution may not work properly.
Henrik:
RFC 3344 is not very clear but the general trend is
that HA selects the capability sent in the registration request
(appendix of RFC3344 indicates this way).
Xxx:
Vendor specific extension may be the solution.
Henrik:
I read the specification before the meeting and it
says you can. It is not very clear in the specification, though, so it
seems that this is an new issue for 3344bis
Action:
It was determined that RFC3344 needs to have further
clarity on encapsulation information negotiation. And, hence, there may
not be any problem which need to be solved by this draft.
Henrik: We are done.
|
