Re: issue 12: interaction with other protocols doing RR
Vijay Devarapalli <[email protected]>
| Newsgroups | gmane.ietf.mobike |
|---|---|
| Message-ID | <[email protected]> |
James Kempf wrote:
> Jari,
>
>
>>*) The example that comes to my mind is that since the
>>mobile node - home agent interface in mobile IPv6 runs
>>with IPsec, then the use of MOBIKE in that context
>>would provide an RR test to home registrations. That
>>does not exist in Mobile IPv6 at the moment, but if
>>it were included then Mobile IPv6 home agent service
>>could easier be offered to "unknown" peers. Currently
>>"unknown" peers are only support as correspondent
>>nodes.
>>
>
>
> IMHO, the lack of HA RR test in RFC 3775 is a residual vulnerability. RFC
> 3775 says that network operators should monitor their clients traffic and
> cut them off if they try bombing. But how is an operator supposed to know
> that? In the absence of any RR test, there's no way for the HA to know
> whether the MN is at the care of address to which it is directing a video
> stream, or whether its a bombing attack. This kind of insider attack is
> still possible.
>
> So I think this is an excellent idea. In fact, I think it should be used not
> just with "unknown" peers but also with known clients of the HA.
I would rather add an RR test to Mobile IP. It could be a
simple Mobility Header message probe protected by IPsec.
a couple of reasons.
1. I am not sure we are going to be using MOBIKE between
a MN and HA (when they are already doing Mobile IPv6
signaling. BU is your MOBIKE update message).
2. no need to have some kind of interaction between the
IKE stack and the Mobile IPv6 stack
Vijay