Hi, At first sorry for the late reply and thanks for the review.
2008/12/17 marcelo bagnulo braun <[email protected]>: > Hi, > > I have done a first review of draft-ietf-csi-sndp-prob-00.txt and i have > some comments > > > 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). > > For Mobile IPv6 Mobile Nodes (MN), it is necessary to keep existing > sessions going even when one leaves the home network. If a Neighbor > is actively delivering packets to a Mobile Node which is at home, > this Neighbor will have a valid Neighbor cache entry pointed at the > MN's link-layer address on the Home link. > > As seen in Figure 1, solicitors send a multicast solicitation to the > solicited nodes address of the absent node (based on the unicast > address). > > I don't follow the logic between the second and the third paragraph > I mean, if the neighbor has a valid cache entry, it doesn't send a NS to the > target node, since it is already in the cache? Or are we talking about NUD > here? I agree it is unclear. Do you think the following text is more clear? NEW TEXT: "For Mobile IPv6 Mobile Nodes (MN), it is necessary to keep existing sessions going or to allow new sessions even when one leaves the home network. For existing sessions, the Proxy (i.e. the Home Agent in Mobile IPv6) sends an unsolicited NA to the all-nodes multicast address on the home link as specified [RFC3775]. For new sessions, the Proxy, which listens to the MN's address responds with a Neighbor Advertisement which originates at its own IPv6 address and has the proxy's address as the Target Link-Layer Address, but contains the absent mobile in the Target Address field of the Neighbor Advertisement. In this case, no solicitations are proxied, as the advertisements originate within the proxy itself. As seen in Figure 1, solicitors send a multicast solicitation to the solicited nodes address of the absent node (based on the unicast address). Absent Mobile Proxy Solicitor NS:SL3=S,DL3=Sol(A),TA=A +-----+ SL2=s,DL2=sol(a),SLL=s | |<================ | | | |================> +-----+ NA:SL3=P,DL3=S,TA=A, SL2=p,DL2=s,TLL=p Legend: SL3: Source IPv6 Address NS: Neighbor Solicitation DL3: Destination IPv6 Address NA: Neighbor Advertisement SL2: Source Link-Layer Address RS: Router Solicitation DL2: Destination Link-Layer Address RA: Router Advertisement TA: Target Address SLL/TLL: Source/Target Link-Layer Address Option Figure 1" OLD TEXT: "For Mobile IPv6 Mobile Nodes (MN), it is necessary to keep existing sessions going even when one leaves the home network. If a Neighbor is actively delivering packets to a Mobile Node which is at home, this Neighbor will have a valid Neighbor cache entry pointed at the MN's link-layer address on the Home link. As seen in Figure 1, solicitors send a multicast solicitation to the solicited nodes address of the absent node (based on the unicast address). Absent Mobile Proxy Solicitor NS:SL3=S,DL3=Sol(A),TA=A +-----+ SL2=s,DL2=sol(a),SLL=s | |<================ | | | |================> +-----+ NA:SL3=P,DL3=S,TA=A, SL2=p,DL2=s,TLL=p Legend: SL3: Source IPv6 Address NS: Neighbor Solicitation DL3: Destination IPv6 Address NA: Neighbor Advertisement SL2: Source Link-Layer Address RS: Router Solicitation DL2: Destination Link-Layer Address RA: Router Advertisement TA: Target Address SLL/TLL: Source/Target Link-Layer Address Option Figure 1 The Proxy, which listens to this address responds with a Neighbor Advertisement which originates at its own IPv6 address and has the proxy's address as the Target Link-Layer Address, but contains the absent mobile in the Target Address field of the Neighbor Advertisement. In this case, no solicitations are proxied, as the advertisements originate within the proxy itself." > In any case, i think it would be good to clarify > > later on, in this same section: > > Where secured proxy services are not able to be provided, a proxy's > advertisement may be overridden by a bogus proxy without it even > knowing the attack has occurred. > > > I don't understand the meaning of this sentence, could you clarify? NEW TEXT: "Where secured proxy services are not able to be provided, a proxy's advertisement may be overridden by a "rogue" proxy without it knows the attack has occurred, exactly like a network where SEND is not deployed." OLD TEXT: " Where secured proxy services are not able to be provided, a proxy's advertisement may be overridden by a bogus proxy without it even knowing the attack has occurred." Is it more clear? > > Later on > 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 think this is clearly described. I mean, section 2.3 also talks > about fixed nodes. In this case, you are considering fixed nodes that are > away from home. Or maybe, nomadic nodes, that are attached to a foreign > network. I think you should describe the scenario in a clearer way and > cahnge the name The goal was to have: - a section (i.e. section 2.1) about proxied (spoofed, in fact) messages on a link where the node may be sometimes (i.e. MN in Mobile IPv6) - a section (i.e. section 2.2) about proxied (spoofed, in fact) messages on a link where the node is never (i.e. Mobile IPv6 with Virtual Home Network or IKEv2) - a section (i.e. section 2.3) about proxied messages using Bridge-like ND Proxy mechanism where original messages are modified and are not created from scratch as in the other previous sections. > > Later on in section 2.3. Bridge-like ND proxies: > > Proxy modification of SEND solicitations and advertisements require > removal of (at least) CGA and Signature options, and may also need > new options with proxy capabilities if non-CGA signatures are added > to SEND. > > I don't understand what you mean here > SEND doesn't work with this, removing the options is not a way to make send > work imho > please rephrase or supress NEW TEXT: "Proxy modification of SEND solicitations and advertisements require removal of (at least) original CGA and Signature options, and may also need new options with proxy capabilities if non-CGA signatures are added to SEND. OLD TEXT: "Proxy modification of SEND solicitations and advertisements require removal of (at least) CGA and Signature options, and may also need new options with proxy capabilities if non-CGA signatures are added to SEND." Do you agree? > > > In order to use the same security procedures for both ND Proxy and > Mobile IPv6, changes may be needed to the proxying procedures in > [RFC4389], > > really? i don't think we are chartered to do that... do you think we should? That depends on the solution(s) the WG will adopt and not the PS document: that's why there is a "may" :) > > Later on, in section 3. Proxy ND and Mobility: > > Where the proxy forwards between segments of a network, nodes may > move between segments [RFC4389]. For this scenario, the proxy is > responsible for updating Neighbor cache entries as incorrect state is > left in them after the move. > > > I am not sure how relevant is all this part. I mean, i understand that you > are considering mobility when a node moves between segments, but i am not > sure if this is one of the problems that we need to solve or even consider. > I mean, for me the question is how relevant is this problem? Seems like a > corner case to me and i would simply remove it. Correct: IMO, this a classical ND scenario (e.g. case where a IPv6 host on a link is shutdown and starts on another link). I agree this text should be removed. > > > Later on, in section 4. Proxy Neighbor Discovery and SEND > > There is no mention of Router advertisement, only neighbor advertisment are > considered, but the proxy ND must also be considered. Please include a > section about RA and RS in this section. OK. > > > Later on, in section 4.1. CGA signatures and Proxy Neighbor Discovery: > > Such a message will validate using SEND, except that > the Target Address field will not match the IPv6 Source Address in > Neighbor Advertisements [RFC3971]. > > well, this message will NOT validate with send actually > could you make this clearer? Sorry, but I don't understand your comment: in replacing the right options (i.e. CGA option and RSA signature option), SEND works. Did I miss something? > > Later on: 5.2.2. Unauthorized routers and proxies > > > Routers advertising on networks without routers may have to operate > with no explicit authorization, > > I can't parse the previous sentence... routers in networks without routers? > > I think the correct sentence is: "Routers advertising on networks may have to operate with no explicit authorization, and SEND hosts will configure these if there's no other option [RFC3971]." Best regards and happy new year! JMC. _______________________________________________ CGA-EXT mailing list [email protected] https://www.ietf.org/mailman/listinfo/cga-ext
