![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
Hi, One concern I've had with this draft is the change in routing. In MIPv4, prior to this, RRQ and RRP has always travelled back and forth between the same two end nodes, while here we introduce a change where a different node than the HA originally addressed by the MN may be answering. Pete has already pointed out 3 issues with this: a) It removes the possibility to do ingress filtering of RRPs, which widens the possibility of DOS attacks by forging rejections b) It seems not to work with co-located CoA registration through FA c) It raises the possibility of routing loops amongst HA's I'd like to add yet another one: d) It seems to me that it also breaks the NAT traversal mechanism, which is rather crucial to a large part of the deployment scenarios we are currently seeing. The port on the NAT from which the original request was issued is lost through the forwarding, and if the Directed HA overwrites the source address, the detection of the NAT is also made impossible. (Actually, if the Directed HA overwrites the source address, an Assigned HA with NAT traversal support would identify the Directed HA as a NAT) For these reasons, I think it would be much better to have a solution where the first (Directed) HA returns an error reply and and indication of the next HA to contact to the MN. This would remove all the objections above, admittedly with the loss of some efficiency, but correct operation has to come before efficiency, as I see it. Henrik
Attachment:
pgp00005.pgp
Description: PGP signature