Problem with [email protected] address email. ---------- Forwarded message ---------- From: Jean-Michel Combes <[email protected]> Date: 2008/12/27 Subject: Re: Review of draft-ietf-csi-sndp-prob-00 To: Julien Laganier <[email protected]> Cc : [email protected], [email protected]
Hi, At first sorry for the late reply and thanks for the review. 2008/12/17 Julien Laganier <[email protected]>: > 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. Do you speak about: (1) all the MAGs must have the same LLA? (2) all the MAGs must advertize the same HNP for a dedicated MN? (1) is described in section 6. (2) this is more or less the Bridge-like ND Proxy scenario Did I miss something? > > Section 3 is a bit lost, I'm feeling it overlaps with Section 2 and thus > should be merged with it. Yes. I agree. I will try to merge this section in the previous previous. > > 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. I must admit I don't support such a idea: I would prefer to have a more general document covering all potential scenarios than a document only describing 2-3 scenarios like RFC 3756 did. > > 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. This is just a description of potential approaches and I think we have to keep it because AFAIK there is no "Solution Space" document today. > > 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. "2. Scenarios This section describes the different scenarios where the interaction between SEND and ND-Proxy raises issues. 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)." "Issue" is linked to the text in section 2. But I can modify the text. NEW TEXT: "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 raised by the interaction between SEND and ND-Proxy is the same with Mobile IPv6 based protocols (e.g. NEMO, HMIPv6)." OLD TEXT: " 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)." Is it better? > > 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. The MAP is a MIPv6-HA and so, AFAIK, needs to proxy ND messages for correspondents on the link from where the RCoA is derived. > > 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. No no: issue is the interaction between SEND and ND-Proxy :) > > " [...] > > 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. OK. Thanks. > > 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. Agree and I understand your feeling. But AFAIK the standard today (i.e. RFC 4306) is multilink subnet based and the "IKEv2 IPv6 address assignment mechanism" document (i.e. draft-ietf-ipsecme-ikev2-ipv6-config) is still under draft status. So the question in fact is: do we have to do the analysis on the standard or the draft? Feedbacks are welcome. > > 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. OK. Thanks. > > > " > [...] 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". NEW TEXT: "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]." OLD TEXT: "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]." > > > " > [...] > 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 OK. Thanks > > " > [...] > 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". Agree. NEW TEXT: "Once again, these messages may not be signed with a CGA signature by the Proxy, because it does not own the source address." OLD TEXT: "Once again, these messages may not be signed with a CGA signature by the re-advertisor, because it does not own the source address." > > " > 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". In fact, maybe, we should remove this text because this is too strongly linked to the solution space ... your opinion? > > " > [...] 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/ OK. But I have the same feeling that the previous comment: this text is too strongly linked to the solution space maybe. > > 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. OK. > > 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]. OK. Thanks. > > " > 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... There is a "may be needed" to let open all potential solutions: this is not a "must" :) > > 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"? That means "Signatures not based on CGA security material" (e.g. security material from certs). > > " 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". OK. > > But again, aren't we entering solution space. What are the solution > requirement? IMHO, there are no new requirements. We have to keep the same security level as in SEND but if the standardized solution will not be able to keep it,IMHO, this is in the solution document that security limitations should be described. > > " 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/ OK. Thanks. > > " 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/ OK. Thanks. > > Hope that is helpful. Sure :) Thanks again. Best regards and happy new year. JMC. > > --julien > -- > --julien > _______________________________________________ CGA-EXT mailing list [email protected] https://www.ietf.org/mailman/listinfo/cga-ext
