Subject: [Mipshop] F-MIPv6: Buffering in PAR Unauthorized?

From: Christian Vogt <[email-masked]>
Date: Tue, 13 Dec 2005 10:32:32 +0100

All,

not sure if this was discussed before:

In F-MIPv6, the PAR may start buffering packets as soon as it has
sent a RtAdvPr message.  This means that an attacker could trigger such
buffering with an unauthenticated RtSolPr message.

Note that Vidia et al.'s handoff-key prototocol [1], currently under
discussion in Mipshop, is designed to authenticate the FBU only.  Do we
also have to authenticate the RtSolPr in order to authorize buffering in
the PAR?

Regards,
- Christian

[1] draft-vidya-mipshop-handover-keys-aaa-01.txt

-- 
Christian Vogt, Institute of Telematics, University of Karlsruhe
www.tm.uka.de/~chvogt/pubkey/

_______________________________________________
Mipshop mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mipshop

---

From: Vidya Narayanan <[email-masked]>
Date: Fri, 16 Dec 2005 23:35:11 +0530

In accordance with FMIP, the PrRtSol ad RtAdvPr can be exchanged at
any time (not just before the handoff, as originally envisioned). So,
it doesn't seem to make sense for the PAR to start buffering as soon
as it sends the RtAdvPr.

Thoughts?

Vidya

---

From: Christian Vogt <[email-masked]>
Date: Sat, 17 Dec 2005 13:35:52 +0100

Hi Vidya.

Hmm, but that's what RFC4068 suggests in section 4:

>    When further protocol action is necessary, some implementations MAY
>    choose to begin buffering copies of incoming packets at the PAR.  If
>    such FIFO buffering is used, the PAR MUST continue forwarding the
>    packets to PCoA (i.e., buffer and forward).  Such buffering can be
>    useful when the MN leaves without sending the FBU message from the
>    PAR's link.  The PAR SHOULD stop buffering after processing the FBU
>    message.  The size of the buffer is an implementation-specific
>    consideration.

[This happens right after the PAR has send the RtAdvPr.]

It might make more sense for the PAR to begin buffering when it's link 
layer is unable to deliver a packet to the mobile node.  Such a 
link-layer hint could serve as an indication that the mobile node has 
left the old link without sending an FBU.

Certainly, this method would depend on properties of the underlying 
link-layer technology.  Specifically, the link layer support have 
acknowledgements, and unsuccessful packet deliveries should be an 
exception (unless the mobile node is gone, of course).

Actually, IEEE 802.11 has both of these properties:  Unicast frames may 
be re-transmitted up to seven times, and they are acked once they are 
received.

If the link layer does not have the two properties, the PAR should 
propably refrain from buffering.  After all, packet buffering in the PAR 
is optional anyway.

Having said this, the authorization problem still exists:  A malicious 
mobile node could still cause the PAR to buffer packets unnecessarily. 
I don't see a solution to this other than to couple such authorization 
with the authentication/authorization exchange of your handoff-key 
protocol [1].  That exchange happens proactively, so in most cases well 
before the MN-PAR link breaks.

Does this sound like an idea?

Regards,
- Christian

---

From: "James Kempf" <[email-masked]>
Date: Mon, 19 Dec 2005 10:52:02 -0800

We looked into this problem quite extensively a few years ago. Our opinion 
was that IP level messages should not be used to try to synchronize link 
handover and IP handover, since many aspects of progressing the basic link 
handover are controlled by the MAC layer, either on the host (as in 802.11) 
or as a collaboration between the host and the network (as in 802.16).

So I support removing the triggering of buffering by PrxyRtSol from the spec 
(in fact, I had thought it was removed). I believe any buffering must be 
triggered by the progress of link handover, and, in some cases (such as 
802.11) might not be possible due to how the link layer implements handover. 
I believe the PrRtSol and RtAdvPr messages should be for information only, 
so the host can determine AP to AR address mappings in advance of being on 
the link where the AP is on.

            jak

----- Original Message ----- 
From: "Christian Vogt" <[email-masked]>
To: "Vidya Narayanan" <[email-masked]>
Cc: "Mipshop" <[email-masked]>; "Rajeev Koodli" <[email-masked]>
Sent: Saturday, December 17, 2005 4:35 AM
Subject: Re: [Mipshop] F-MIPv6: Buffering in PAR Unauthorized?

> layer is unable to deliver a packet to the mobile node.  Such a link-layer 
> hint could serve as an indication that the mobile node has left the old 
> link without sending an FBU.
>
> Actually, IEEE 802.11 has both of these properties:  Unicast frames may be 
> re-transmitted up to seven times, and they are acked once they are 
> received.
>
> mobile node could still cause the PAR to buffer packets unnecessarily. I 
> don't see a solution to this other than to couple such authorization with 
> the authentication/authorization exchange of your handoff-key protocol 
> [1].  That exchange happens proactively, so in most cases well before the 
> MN-PAR link breaks.
>

---

From: Christian Vogt <[email-masked]>
Date: Tue, 20 Dec 2005 08:44:11 +0100

James -

thanks for the background info.

> So I support removing the triggering of buffering by PrxyRtSol from
> the spec (in fact, I had thought it was removed). I believe any
> buffering must be triggered by the progress of link handover, and, in
> some cases (such as 802.11) might not be possible due to how the link
> layer implements handover. [...]

I agree.  And as mentioned in my previous email, I tend to suggest that 
frame-delivery failures at the link layer could be such an trigger for 
some link layers.

802.11 has inbuilt retransmission and acknowledgement mechanisms. 
Therefore, it should be ok to assume handoff in the event of a 
to-be-determined number of back-to-back delivery failures.

Ultimately, the buffering policy is up to the PAR, of course.

 > [...]  I believe the PrRtSol and RtAdvPr messages
 > should be for information only [...].

Ack.  That would probably make it easier to develop a handoff-key 
protocol, too.

Regards,
- Christian

James Kempf wrote:
> We looked into this problem quite extensively a few years ago. Our 
> opinion was that IP level messages should not be used to try to 
> synchronize link handover and IP handover, since many aspects of 
> progressing the basic link handover are controlled by the MAC layer,
>  either on the host (as in 802.11) or as a collaboration between the
> host and the network (as in 802.16).
> 
> So I support removing the triggering of buffering by PrxyRtSol from
> the spec (in fact, I had thought it was removed). I believe any
> buffering must be triggered by the progress of link handover, and, in
> some cases (such as 802.11) might not be possible due to how the link
> layer implements handover. I believe the PrRtSol and RtAdvPr messages
> should be for information only, so the host can determine AP to AR
> address mappings in advance of being on the link where the AP is on.
> 
> jak
> 
> ----- Original Message ----- From: "Christian Vogt"
> <[email-masked]> To: "Vidya Narayanan" <[email-masked]> 
> Cc: "Mipshop" <[email-masked]>; "Rajeev Koodli"
> <[email-masked]> Sent: Saturday, December 17, 2005 4:35 AM 
>>> In accordance with FMIP, the PrRtSol ad RtAdvPr can be exchanged
>>> at any time (not just before the handoff, as originally
>>> envisioned). So, it doesn't seem to make sense for the PAR to
>>> start buffering as soon as it sends the RtAdvPr.
>> 
>>> When further protocol action is necessary, some implementations
>>> MAY choose to begin buffering copies of incoming packets at the
>>> PAR.  If such FIFO buffering is used, the PAR MUST continue
>>> forwarding the packets to PCoA (i.e., buffer and forward).  Such
>>> buffering can be useful when the MN leaves without sending the
>>> FBU message from the PAR's link.  The PAR SHOULD stop buffering
>>> after processing the FBU message.  The size of the buffer is an
>>> implementation-specific consideration.
>> 
>> 
>> It might make more sense for the PAR to begin buffering when it's
>> link layer is unable to deliver a packet to the mobile node.  Such
>> a link-layer hint could serve as an indication that the mobile node
>> has left the old link without sending an FBU.
>> 
>> Actually, IEEE 802.11 has both of these properties:  Unicast frames
>>  may be re-transmitted up to seven times, and they are acked once
>> they are received.
>> 
>>  propably refrain from buffering.  After all, packet buffering in
>> the PAR is optional anyway.
>> 
>> Having said this, the authorization problem still exists:  A
>> malicious mobile node could still cause the PAR to buffer packets
>> unnecessarily. I don't see a solution to this other than to couple
>> such authorization with the authentication/authorization exchange
>> of your handoff-key protocol [1].  That exchange happens
>> proactively, so in most cases well before the MN-PAR link breaks.
>> 
>> Regards, - Christian
>>> In accordance with FMIP, the PrRtSol ad RtAdvPr can be exchanged
>>> at any time (not just before the handoff, as originally
>>> envisioned). So, it doesn't seem to make sense for the PAR to
>>> start buffering as soon as it sends the RtAdvPr.
>>> 
>>> Thoughts?
>>> 
>>> Vidya
>>> 
>>>> In F-MIPv6, the PAR may start buffering packets as soon as it
>>>> has sent a RtAdvPr message.  This means that an attacker could
>>>> trigger such buffering with an unauthenticated RtSolPr message.
>>>> 
>>>> 
>>>> Note that Vidia et al.'s handoff-key prototocol [1], currently
>>>> under discussion in Mipshop, is designed to authenticate the
>>>> FBU only.  Do we also have to authenticate the RtSolPr in order
>>>> to authorize buffering in the PAR?
>>>> 
>>>> Regards, - Christian
>>>> 
>>>> -- Christian Vogt, Institute of Telematics, University of
>>>> Karlsruhe www.tm.uka.de/~chvogt/pubkey/

---

From: "James Kempf" <[email-masked]>
Date: Tue, 20 Dec 2005 08:30:51 -0800

> Ultimately, the buffering policy is up to the PAR, of course.

Hmm, not so sure about this. How can the PAR distinguish between a frame 
delivery failure due to handover and one due to the terminal going down (or 
perhaps link transmission is disrupted by an adversary)?

Note that even if the PAR buffers, it still must know where to send the 
data, which it won't until an FBU arrives.

            jak