I have reviewed draft-ietf-csi-sndp-prob-00. These are my comments:
Review Summary:
---------------
Section 2: the scenario part does overall a good job at sketching
current usage of ND proxies (altough it misses the PMIPv6 use case that
we documented in draft-ietf-csi-proxy-send) and discussing why it break
SENDs.
Section 3 is a bit lost, I'm feeling it overlaps with Section 2 and thus
should be merged with it.
Section 4 and 5 are IMHO reaching far too much into solution space, yet
the document hasn't slated a trust model for operating ND proxies,
which I think is clearly part of the problem statement.
Thus I feel I'm missing the most important part of the problem
statement. What I'd like to see is a document structured around one or
more documented trust model (maybe aking to what RFC 3756 did),
explaining what the ND proxy does, who owns it, what authority it has
and where it gets it from. There can be one or more trust model
depending on their applicability to different usage scenarios (e.g.
bridge like ND proxies, MIPv6 HA proxying, PMIPv6 MAG proxying). Then
there can be the explanation why the current SEND isn't sufficient for
each of the trust model.
Then I think we are done with the problem statement and we do not need
the part on "potential approaches to secure proxy ND" as in section 5
of the current document, which belongs to solution space IMHO.
Detailed Review:
----------------
I had started a detailed review, wordsmithing etc. but I stopped within
Section 4.2 when I realized the document structure wasn't convincing to
me and thought I'd better give high level comments rather than sentence
level suggestions. FWIW I'm anyway copying the beginning of detailed
review I performed below.
2.1. IPv6 Mobile Nodes and Neighbor Discovery Proxy
----------------------------------------------------
" When moving in the Internet, the aim of IPv6 mobility is to allow a
device continued packet delivery, whether present on its home network
or not. The following text is focused on Mobile IPv6 but the issue
is the same with Mobile IPv6 based protocols (e.g. NEMO, HMIPv6).
"
The text about the "issue" above is confusing.
First, what is the "issue"? Is this the general issue of maintaining
existing communications for mobile hosts, or is it specific to the
neighbor discovery proxy function introduced to cope with the existence
of the home link. That should be clarified.
Second, if the "issue" is with the Neighbor Discovery Proxy function, I
understand that there's no "issue" with HMIPv6 because HMIPv6 has no
notion of home link per se and thus does not need a ND proxy function.
Third, if the "issue" is with maintaining existing communications for
mobile hosts, I do not think we need to talk about HMIPv6 there since
this document is not a problem statement for a mobility protocol.
" [...]
If Cryptographically Generated Addressing (CGA) [RFC3972] is
available, the MN may be able to secure its Neighbor cache bindings
while at home using Secured Neighbor Discovery (SEND) [RFC3971].
SEND assumes that the address owner is the advertiser and therefore
has access to the keys required to sign advertisements about the
address. Movement away from the home link requires that a proxy
undertake Neighbor Discovery.
In Mobile IPv6, the role of the proxy is undertaken by the Home
Agent. While the Home agent has a security association with the MN,
it as proxy will not have access to the public-private key pair used
to generate the MN's cryptographic address. This prevents Proxy
Neighbor Discovery from using SEND as defined [RFC3971].
Where a host moves from the home network to a visited network, the
proxy needs to override existing valid Neighbor cache entries which
may have SEND protection. This is needed in order to redirect
traffic to use the proxy's link-layer address, allowing packets to
flow onto the tunnel connecting the Home Agent/Proxy and the MN.
With current specifications, any solicitation or advertisement sent
by the proxy will not be able to update the MN's home address if the
existing NC entry is protected by SEND. Such existing Neighbor cache
entries will time-out after Neighbor Unreachability Detection
[RFC4861].
"
Suggest rewording:
While at home, if the MN has configured Cryptographically Generated
Addresses (CGAs) [RFC3972], it can secure establishment by its on-link
neighbors of Neighbor Cache Entries (NCEs) for its CGAs by using Secure
Neighbor Discovery (SEND) [RFC3971]. SEND security requires a node
sending Neighbor Advertisments for a given address to be in possession
of the public-private key pair that generated the address.
When a MN moves away from the home link, a proxy has to undertake
Neighbor Discovery signaling on behalf of the MN. In Mobile IPv6, the
role of the proxy is undertaken by the Home Agent. While the Home agent
has a security association with the MN, it does not have access to the
public-private key pair used to generate the MN's CGA. Thus the Home
Agent acting as an ND proxy cannot use SEND for the address it is
proxying [RFC3971].
When a MN moves from the home network to a visited network, the proxy
will have to override the MN's existing Neighbor Cache Entries which
are flagged as secure [RFC3971]. This is needed for the Home Agent to
intercept traffic sent on-link to the MN that would otherwise be sent
to the MN's link layer address.
With the current SEND specification, any solicitation or advertisement
sent by the proxy will be unsecure and thus will not be able to update
the MN's NCE for the home address because it is flagged as secured.
These existing Neighbor Cache Entries will only time-out after Neighbor
Unreachability Detection [RFC4861] concludes the Home Address is
unreachable at the link layer recorded in the NCE.
2.2. IPv6 Fixed Nodes and Neighbor Discovery Proxy
---------------------------------------------------
" This scenario is a sub-case from the previous one. The IPv6 node
will never be on the link where the ND messages are proxied. This is
case with IKEv2 [RFC4306] when a node needs an IP address in the
network protected by a security gateway and this latest assigns it
dynamically using Configuration Payload during IKEv2 exchanges. The
security gateway will have to proxy ND messages to be able to
intercept messages, sent to the node, to tunnel them to this latest.
"
I don't really agree with the statement that this scenario is a subcase
of the previous one. I understand the scenario as follows: a VPN GW
assigns to multiple MNs IPv6 addresses from an aggregated prefix.
I think the scenario describes a bad deployment practice that we
shouldn't be concerned about. The prefix shouldn't be advertized on a
link inside the VPN GW's network otherwise this is a multilink subnet.
2.3. Bridge-like ND proxies
----------------------------
" Where proxies exist between two segments, messages may be sent by the
proxy on the far link, in order to gain or pass on Neighbor
information. [...]
"
This is obscure. How about:
The Neighbor Discovery (ND) Proxy specification [RFC4389] provides a
method by which multiple link layer segments are bridged into a single
segment and specifies the IP-layer support that enables bridging under
these circumstances.
"
[...] The proxy in this case forwards messages while
modifying their source and destination MAC addresses, and rewrites
their Link-Layer Address Options solicited and override flags. This
is defined in Bridge Like ND Proxy (ND Proxy) [RFC4389].
"
I think a coma is missing after "Options".
"
[...]
ND Proxy resends messages containing their original address, even
after modification [RFC4389]. Figure 2 describes packet formats for
proxy Neighbor solicitation and advertisement as specified by the
specification.
"
s/ND Proxy/An ND proxy
"
[...]
Once again, these messages may not be signed with a CGA signature by
the re-advertisor, because it does not own the source address.
"
"re-advertisor" is coming out of the blue here. Someone not familiar
with ND and ND proxies might miss the point... Can we use a better
term, or define "re-advertisor".
"
Additionally, multicast Authorization Delegation Discovery ICMPv6
messages need to be exchanged for bridge-like ND proxies to prove
their authority to forward. [...]"
I suggest to remove "multicast" and "ICMPv6" as it's details ortoghonal
to the issue at stake here. Also, the authority is to act as a router
for one or more prefix(es) rather than "forward".
"
[...] Unless the proxy receives explicit
authority to act as a router, or the router knows of its presence, no
authorization may be made. This explicit authorization requirement
may be at odds with zero configuration goal of ND proxying [RFC4389].
"
s/with zero/with the/
3. Proxy ND and Mobility
-------------------------
Why do we have this section at all? It seems to be overlapping with the
2.x section and probably should be merged with those.
4.1. CGA signatures and Proxy Neighbor Discovery
-------------------------------------------------
"
Where a proxy replaces the message source with its own CGA, the
existing CGA option and RSA signature option need to be replaced with
the proxy's. Such a message will validate using SEND, except that
the Target Address field will not match the IPv6 Source Address in
Neighbor Advertisements [RFC3971].
"
Suggest reword into: When a proxy replaces the message source IPv6
address with its own CGA, as per SEND specification the existing CGA
option and RSA signature option would need to be replaced with the
proxy ones. Such a message would be valid according to the SEND
specification, weren't the Target Address and the source IPv6 address
of the Neighbor Advertisement different [RFC3971].
"
Additional authorization information may be needed to prove that the
proxy is indeed allowed to advertise for the target address, as is
described in Section 5.
"
Isn't this already going to far into solution space?
We haven't spelled yet what are our solution requirements (ala RFC3756)
which is clearly part of the problem statement yet we're coming up with
the need for an additional authorization information...
4.2. "Non-CGA signatures and Proxy Neighbor Discovery"
------------------------------------------------------
The term "Non-CGA signatures" is not the best IMHO. Do you want to
say "Message not protected with the CGA option"?
" Where a proxy retains the original source address in a proxied
message, existing SEND-CGA checks will fail, since fields within the
message will be changed. In order to achieve secured proxy Neighbor
discovery in this case, new signature authentication mechanisms may
be needed for SEND.
"
Suggest to reword "new signature authentication mechanisms may be needed
for SEND" into "extended authorization mechanisms will be required".
But again, aren't we entering solution space. What are the solution
requirement?
" SEND provides interfaces for extension of SEND to non-CGA based
authorization. Messages are available for Authorization Delegation
Discovery, which is able to carry arbitrary PKIX/X.509 certificates
[RFC5280].
"
s/interfaces/mechanisms/
" There is no specification though of keying information option formats
analogous to the SEND CGA Option [RFC3971]. The existing option
allows a host to verify message integrity by specifying a key and
algorithm for digital signature, without providing authorization for
functions other than CGA ownership.
"
s/no specification though/however no specification/
s/for functions other/via other mechanism/
Hope that is helpful.
--julien
--
--julien
_______________________________________________
CGA-EXT mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cga-ext
