[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MEXT] EXTENDED [WGLC] RFC 3775 bis / draft-ietf-mext-rfc3775bis
Hello Arnaud,
I have made the changes as we have discussed.
Additional comments inline below:
Arnaud Ebalard wrote:
5.3. Dynamic Home Agent Address Discovery
No security is required for dynamic home agent address discovery.
May be it is the way I understanded it but this sounds like "no security
is needed". It should sounds like "No security is provided for that
mechanism".
I replaced this sentence by the following:
Dynamic home agent address discovery has been designed for use in
deployments where security is not needed. For this reason, no
security solution is provided in this document for dynamic home agent
address discovery.
6.1.7. Binding Update Message
....
Home Registration (H)
The Home Registration (H) bit is set by the sending mobile node to
request that the receiving node should act as this node's home
agent. The destination of the packet carrying this message MUST
be that of a router sharing the same subnet prefix as the home
address of the mobile node in the binding.
This prevents the MN to communicates with the HA on another
interface. Is there any reason for that limitation, i.e. not having a
SHOULD here instead of a MUST. Or I should ask, what is the reason to
have a MUST here.
For instance, the main connectivity of the home agent can be provided by
a given provided (symmetric line) while the MN are on a subnet for which
the prefix is provided by another provider. That way, the download
bandwidth used by the MNs is not shared with the upload bandwidth:
ISP1 -- home subnet ---[HA]--- ISP2
I am willing to change the MUST to a SHOULD, since the message is
secure and the mobile node ought to be able to decide its fate. But,
I would only do so if this seemingly slight change were approved by
the working group. I think it goes beyond the kinds of clarifications and
improvements I can unilaterally decide to do.
In a Router Advertisement, a home agent MUST, and all other routers
MAY, include at least one Prefix Information option with the Router
Address (R) bit set. Neighbor Discovery specifies that, if including
all options in a Router Advertisement causes the size of the
Advertisement to exceed the link MTU, multiple Advertisements can be
sent, each containing a subset of the options [20]. Also, when
sending unsolicited multicast Router Advertisements more frequently
than the limit specified in RFC 4861 [20], the sending router need
s/RFC 4861 [20]/Neighbor Discovery [20]/
IMHO, this is easier to read. Note that there are various places in the
document where the replacement should be done.
O.K. In this particular paragraph, the same document was cited twice, but
in two different ways stylistically. I think it would be better like this:
In a Router Advertisement, a home agent MUST, and all other routers
MAY, include at least one Prefix Information option with the Router
Address (R) bit set. Neighbor Discovery (RFC 4861 [20]) specifies
that, when including all options in a Router Advertisement causes the
size of the Advertisement to exceed the link MTU, multiple
Advertisements can be sent, each containing a subset of the Neighbor
Discovery options. Also, when sending unsolicited multicast Router
Advertisements more frequently than the limit specified in RFC 4861,
the sending router need not include all options in each of these
Advertisements.
The citation is made only once in the paragraph, both the protocol name and
the RFC number are clearly associated, and a small bit of repetitive
verbosity
is reduced. I'll try to treat the other instances with the same philosophy.
Thanks for pointing them out.
8.4. IPv6 Home Agents
...
No opinion on whether this is a good idea or not, but probably worth
asking: what about also adding a reference to RFC 4389 (experimental
doc)?
I don't think that the simple existence of an experimental document that
describes various features of proxy ND agents is a strong argument for
inclusion. Did you check whether the RFC 4389 specifications are fully
compatible with Mobile IPv6 as currently specified? I think it would be
wise to do so before making the citation. If there are cases that are
handled better in RFC 4389 (e.g., ICMP messaging, neighbor cache
operations), then it would be a good idea to (a) make Mobile IPv6
more correct and then (b) cite RFC 4389. I don't think we can rely
on RFC 4389 to identify the correct behavior, however, because then
the citation would be normative and that would be trouble for an
experimental RFC.
That's a long way of saying I am quite leery of making this citation.
But I'm interested to hear your further comments, and especially if
you have assurance that there are no incompatibilities between
RFC 4389 and rfc3775bis.
>>> o The node MAY support stateful address autoconfiguration mechanisms
>>> such as DHCPv6 [32] on the interface represented by the tunnel to
>>> the home agent.
>>>
>>
>> How is that supposed to happen/work? Is that to support provisioning of
>> *additional* addresses (not HoA) from the Home Network? It is unclear.
>>
>
> What if (a) the mobile node gets an address from DHCP and then
> (b) runs IKE with its home agent?
Sorry, I do not understand what you mean. Can you describe more
precisely the steps? The tunnel does not even exist prior to the binding
(which require the HoA) so I don't see how this can work.
> How should the statement be made clearer?
Well, I don't even see how this can work so at the moment, I would
remove that item.
I should have thought more about this before answering the first time.
I agree it isn't clear, because I think there are several scenarios.
First, we can agree that mobile nodes MAY support DHCPv6, right?
The question is how to make it work. And rfc3775bis might not be the
right place for that.
But here are some (slightly) better considered ideas.
- the mobile node might use DHCPv6 for configuration information
other than its IPv6 address
- the mobile node might use DHCPv6 to extend the lifetime of its
existing home address
- the mobile node might try to use its existing home address, but
get a new address from the DHCPv6 server in reply.
- for such a new home address, it might need to use IKEv* to
make a new security association
- perhaps the old address is still valid for a short time while the
new IKEv2 packets are tunneled with the home agent
- the mobile node should be able to run DHCPv6 to get care-of
addresses to be used on the same network interface as
is used to support the tunnel to the home agent.
I don't claim that having the abovementioned possibilities makes
the bulleted item in question any more clear, but I'm not sure
how to make it clearer, and I somehow don't think that section
is the right place to lay out all the possibilities for DHCPv6
interactions.
So unless someone tells me different, for now I'll just leave
it alone.
attempt to intercept packets on the mobile node's home link that are
addressed to the mobile node.
In order to do this, when a node begins serving as the home agent it
MUST multicast onto the home link a Neighbor Advertisement message
[20] on behalf of the mobile node.
As specified in section 10.3.1:
Unless this home agent already has a binding for the given home
address, the home agent MUST perform Duplicate Address Detection [21]
on the mobile node's home link before returning the Binding
Acknowledgement.
So, the last sentence should be modified to indicate that the NA is sent
only after that initial DAD.
How about:
In order to do this, when a node begins serving as the home agent it
MUST have performed Duplicate Address Detection (as specified in
Section 10.3.1), and subsequently it MUST multicast onto the home
link a Neighbor Advertisement message [20] on behalf of the mobile
node.
o In addition, for all security associations bound to the mobile
node's home address established by IKE, the mobile node MUST
include an ISAKMP Identification Payload [6] in the IKE phase 2
exchange, giving the mobile node's home address as the initiator
of the Security Association [5].
The Key Management Mobility Capability (K) bit in Binding Updates and
Acknowledgements can be used to avoid the need to rerun IKE upon
movements.
Considering the mechanism is implemented and such an interface needed to
support that, 3775bis could at least point MIGRATE doc given below as an
informational reference document. This clarifies the need and gives a
possible solution.
http://tools.ietf.org/html/draft-ebalard-mext-pfkey-enhanced-migrate-00
So that I can finish revising rfc3775bis before having to stop and read
that draft,
can you provide some suggested text for the proposed citation? I'll try
to read the
draft in the next few days understand your citation and text.
o Given the availability of the home prefix, the MN checks whether
or not the home prefix matches one of the prefixes received in the
RA. If it does, the MN concludes that it has returned home.
It should be stated here or in the "Security Considerations" section
that this procedure is insecure and may have security impact, as we rely
on basic ND and undergo associated threats. This is documented:
http://tools.ietf.org/html/draft-ebalard-mext-hld-security-00
How about:
o Given the availability of the home prefix, the MN checks whether
or not the home prefix matches one of the prefixes received in the
RA. If it does, the MN concludes that it is connected to the home
link. Please see Section 15.10 for information regarding the
security vulnerability associated with this determination.
and,
15.10. Vulnerabilities from Neighbor Discovery
The ``Home Link Detection'' mechanism (Section 11.5.2) allows the MN
to detect when it is at home. When a MN detects it is at home, it is
expected to deregister, and also (if in use) to stop IPsec protection
for data traffic exchanged over the tunnel to its Home Agent.
Unfortunately, Neighbor Discovery is not a secure protocol. It is
possible that some networks may harbor malicious routing agents that
might advertise false information which would lead a mobile node to
erroneously determine that it had returned to its home network.
A draft [40] has been written that discusses the possible threats
and security impacts associated with the use of this insecure NDP-
based mechanism as a trigger to drop IPsec protection of data traffic
for the MN. It also provides some results on the implementation of
the attacks against an existing MIPv6 module. Possible solutions are
suggested.
And, finally:
17. Acknowledgements
We would like to thank the members of the Mobile IP and IPng Working
Groups for their comments and suggestions on this work. We would
particularly like to thank (in alphabetical order) ...
I wonder if anyone noticed the names had not been in alphabetical order
:-) for a really long time.
There is still one more issue I am working on before considering this
revision to be complete.
But I thought it would be better to send this long-ish email out first
because it will take me a
while to puzzle over that issue. Plus there are all those citations to
modify.
Regards,
Charlie P.