Re: [Mip4] RFC 3344 - Home Agent Registration Code 132 -foreignagent failed authentication
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Mip4] RFC 3344 - Home Agent Registration Code 132 -foreignagent failed authentication



Hello Kent,

Regarding the case:

- MN-HA authentication fails, FA-HA authentication:
    -- MN-HA SA exists ==>  MUST send #131
    -- no MN-HA SA  ==>  MUST silently drop

you wrote:
Kent Leung (kleung) wrote:
> ....       In the last case, it's better that HA SHOULD
> send #131 when MN-HA authentication failed (SA exists) because of the
> following reasons:
> 	- Pending registration entries can be limited so resource
> consumption is not an issue
> 	- Badly behaving MNs that sends unauthenticated RRQs can be
> controlled by the above function in addition to L2 association checks
> 	- Allow flexibility for HA to not respond to RRQ which failed
> MN-HA authentication
>
>   

I think the case is stronger for MUST, though.  No pending registration
record is required for the rejection, and rate limiting can help to take 
care
of misbehaving MNs (... or, did I miss your point here?).  Whether or not
the HAs should have the flexibility is the issue.  Here, it seems to me that
the HA should help "known" MNs to distinguish between simple network
outage/unavailability versus inoperative security.

I hope we can hear from other WG members and get this issue
finally nailed down.

Regards,
Charlie P.




> -----Original Message-----
> From: mip4-bounces at ietf.org [mailto:mip4-bounces at ietf.org] On Behalf Of
> Charles E. Perkins
> Sent: Monday, August 25, 2008 1:32 PM
> To: Kent Leung (kleung)
> Cc: Mobile IPv4 Mailing List; Ahmad Muhanna
> Subject: Re: [Mip4] RFC 3344 - Home Agent Registration Code 132
> -foreignagent failed authentication
>
>
> Hello Kent,
>
> I think there are several cases, and that each case could likely have
> different answers.  The original issue was about the FA-HA
> authentication, but I agree with you that the case of the MN-HA
> authentication is important.
>
> I think these are the relevant cases, with some suggested actions for
> each case.
> - FA-HA authentication fails:
>     -- FA-HA SA exists ==>  MAY send #132
>     -- no FA-HA SA  ==>  MUST silently drop
>
> - MN-HA authentication fails, no FA-HA SA:
>     -- MN-HA SA exists ==>  MAY send #131
>     -- no MN-HA SA  ==>  MUST silently drop
>
> - MN-HA authentication fails, FA-HA authentication:
>     -- MN-HA SA exists ==>  MUST send #131
>     -- no MN-HA SA  ==>  MUST silently drop
>
> Here, in the last case when there is no SA with the mobile node, the
> foreign agent can soon clean up its pending registration list.  Since
> the FA has proved its identity to the HA, it could eventually infer by
> the lack of RREQs from the HA, even after retries by the MN, that the MN
> was not known to the home agent.
>
> Another possibility would be to assign a new error code for a RREQ that
> was purely for the purpose of notifying the FA that the mobile node was
> unknown.
> Then the FA would not forward this RREQ to the MN, but just expunge its
> pending registration entry.
>
> What do you think?
>
> Regards,
> Charlie P.
>
>
>
>   

-- 
Mip4 mailing list: Mip4 at ietf.org
    Web interface: https://www.ietf.org/mailman/listinfo/mip4
     Charter page: http://www.ietf.org/html.charters/mip4-charter.html
Supplemental site: http://www.mip4.org/



Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.