Subject: RE: [mobile-ip] Consensus to include recent piggybacking proposal ?

From: "Karen E Nielsen (TED)" <[email-masked]>
Date: Mon, 18 Mar 2002 00:20:23 +0100

Hi Viray,

I agree that the conflict between piggybacking and intermediate routers having IPSEC policies
that the MN's and the CN's not are aware off is non-relevant in the current proposal. 

However, the problem with the new proposal and the RR messages
is that the requirement that the RR messages (2b. and,
perhaps, 2a.)) should be protected in secure tunnels HA-MN means that 
NOT ONLY can these messages not be piggybacked - but they MUST be implemented as final
protocol elements in order to be detectable by the IPSEC selectors.

In other words the extension header approach will not be usable for the 
2a. and 2b. RR messages. So if you want to go with the extension header
approach, then half the RR messages must be implemented in a final protocol
element and half in an extension header. 
 
Karen

> -----Original Message-----
> From: Vijay Devarapalli [mailto:[email-masked]]
> Sent: 15. marts 2002 22:57
> To: [email-masked]
> Subject: Re: [mobile-ip] Consensus to include recent piggybacking
> proposal?
> 
> 
> "Hesham Soliman (ERA)" wrote:
> > 
> > Charlie,
> > 
> >   > > Karen Nielsen sent two emails to highlight
> >   > > the inability to piggyback some RR messages
> >   > > since they are placed in IPsec tunnels
> >   > > by the HA. You can generalise the same
> >   > > problem for Security Gateways, in those cases
> >   > > the MN might not be aware of security policies by
> >   > > intermediate routers (SGs).
> >   >
> >   > This is not an issue with the current proposal,
> >   > as Vijay has pointed out.
> > 
> > => As Vijay pointed out in his most recent email,
> > there could be issues with piggybacking 1a and
> > 2a. Karen can speak for herself, but reading the
> > last email, it said something like 'strongly
> > stress ....that piggybaking 1a and 2a is not possible'.
> 
> Hesham, 
> 
> I said either way is fine. That is *NOT* the issue here....
> 
> Vijay
> 
> > 
> > Also the other point was SGWs which the MN is
> > not aware of.
> > 
> >   >
> >   > > Also the note was only relevant to IPsec and
> >   > > didn't address the QoS issues (e.g. when using
> >   > > Diffserv e2e or when having the Diffserv bits
> >   > > set by intermediate routers). These comments
> >   > > were explicitly made by David Oran and to some
> >   > > extent in my earlier emails.
> >   >
> >   > I responded at length to those e-mails.  There is no
> >   > issue with respect to piggybacking and QoS,
> >   > _unless_ you are trying to have some sort of
> >   > "implicit" QoS without asking for it.  In any
> >   > other case, the QoS signalling would trivially
> >   > be able to handle any setup required for
> >   > deciding whether or not to use piggybacking.
> > 
> > => First of all, no one is using e2e QoS signalling
> > today, please correct me if I'm wrong.
> > Second, I might have missed on of your emails
> > but I'd appreciate a pointer on how
> > Diffserv can be used here if there is a conflict
> > between the BU DSCPs and the payload's.
> > Obviously Diffserv is not always used e2e and
> > can be set by intermediate routers.
> > 
> > Hesham
>

---

From: Vijay Devarapalli <[email-masked]>
Date: Sun, 17 Mar 2002 20:10:09 -0800

hi Karen,

> that the MN's and the CN's not are aware off is non-relevant in the current proposal. 

good.

> protocol elements in order to be detectable by the IPSEC selectors.

Okay. 2a and 2b cant be piggybacked (that means final Mobility
Header). Fine with me.

> element and half in an extension header. 

So?? I dont see the problem. 1a and 1b are initiated by MN (HoTI
and CoTI). And 2a and 2b (HoT and CoT) are responses from the CN.
Or I am too tired to figure out what you are saying....

are you at the IETF?

regards
Vijay