Subject: RE: [mobile-ip] MIPv6 - Focus of the security discussion

From: "Glenn Morrow" <[email-masked]>
Date: Fri, 19 Oct 2001 15:18:58 -0500

Mike,

I'm sorry no one ever responded to this before. Here is an example I hope
meets your criteria:

WI-FI enhanced with priority contingence and an SBM such a media. 

- Seems to meet the shared media requirement
- Seems to meet the better than best effort
- Seems reasonable for all types traffic as well

I guess we could add regular ethernet with 802.1p and an SBM as well i.e. 
I think it would be very useful if the WAN component for these media is
something like a good old T1, cable modem or DSL, 802.16 etc.. etc.. etc..
to manage bandwidth for all (layer 5 protocols) accross this WAN link and
WAN links on the other side. RSVP with a binding update piggybacked would be
very useful for managing bandwidth for both real-time and other
communications with handoff as a component.

For the ROHC, ROHC is doing special things already. It is a middle-box
technology - similar to a NAT in some ways. It can do special things with a
binding update, too - just like it does for everything else.

I'm sorry - I'm just not buying your arguments.

regards,

Glenn

> 
>    I specifically asked for an example on a shared media,
>    with better than best effort QoS, and in particular
>    suitable for real time traffic. The quoted note was
>    an abbreviated form of that question.
> 
>    Also: header compression/suppression and layer two
>    blocking mitigates many of the bandwidth issues,
>    and does it for far more than just binding updates.
> 
> 	    Mike
>

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 19 Oct 2001 16:07:36 -0500

Hi again Glenn,
  I am going to reply to your two consecutive mails, just on RSVP and
layering:
1. RSVP. Firstly mipv6 allows sending BUs separately (as I said in my
email yesterday, mipv4 mandates, i.e. not only allows but requires, this
already for registration requests), i.e. not piggybacked, so how are
going to achieve what you wish to have as a required behaviour?
This answer is you need to standardize. An example such thing is in
AAA-mipv4 application defined in draft-ietf-aaa-diameter-mobileip-07.txt
(nicely defined by Pat and Charlie!)
2. You said in your mail:
Modularity is achieved the same way that modularity is acheived in a
packet containing IP, TCP and HTTP.

This is because HTTP is an application layer protocol, it uses TCP as
the transport layer, i.e. L4 which in turn uses IP as the network layer,
i.e. L3.
A bit of lesson on OSI layering, please.

Kind regards,

Glenn Morrow wrote:

>
>
> Mike,
>
> I'm sorry no one ever responded to this before. Here is an example I
> hope meets your criteria:

--
Behcet

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 19 Oct 2001 17:19:00 -0500

Charlie, Mike,Glenn, Hesham, Pekka, Jari, et al.

Let me summarize the discussion on piggbacking BUs.
Unlike mipv4, mipv6 allows BU/Back to be piggybacked with data and with
higher layer traffic using extension headers of IPv6.
This has been all OK until security problem has been discovered in route
optimization which happens to start with a BU sent to a CN.
It seems that the security experts (not me) will be able to secure
BU/Backs more easily if they are not piggybacked (solution 6.2 in Arkko
draft).

  If there are no security problems in mipv6 (solution 6.4 in Arkko
draft) then status quo is good enough. Some people seem to be strongly
on this side.
Count me on this, provided that you can convince the chairs Phil and
Raj.

  Otherwise, we seem to have not much choice but to modify a bit the
draft and make BU/Backs more visible in the packet, just like mipv4 (the
details to be worked out).
I can provide conceptual arguments for this choice: BU/Back are
registration/control messages so they'd better be separated from the
data traffic. If they need to be piggybacked with some higher layer
packets (as in AAA mipv4 extension, and as some people argue for RSVP)
then we need to specify this.
Therefore, count me on this too.

  My 0.02 euros.

--
Behcet