Subject: RE: [Mip4] Re: rfc3012bis draft review

From: "Jayshree Bharatia" <[email-masked]>
Date: Tue, 14 Oct 2003 13:58:10 -0500

Inline response...

> -----Original Message-----
> From: Henrik Levkowetz [mailto:[email-masked]] 
> Sent: Tuesday, October 14, 2003 1:45 PM
> To: Bharatia, Jayshree [RICH1:2H13:EXCH]
> Cc: [email-masked]'; [email-masked]'; [email-masked]
> Subject: [Mip4] Re: rfc3012bis draft review
> 
> 
> Hi Jayshree
> 
> 	(I'm adding the mip4 list to the recipients. This should go on 
> the list.)
> 
> Tuesday 14 October 2003, Jayshree wrote:
> > > > > > Your proposal for section is to
> > > > > > re-add the following text:
> > > > > > 
> > > > > > "Whenever a Foreign Agent updates a field of the 
> Registration 
> > > > > > Reply (as suggested in section 3.2), it invalidates the 
> > > > > > authentication data supplied by the Home Agent in the MN-HA 
> > > > > > Authentication extension to the Registration Reply.  Thus, 
> > > > > > this opens up a security exposure whereby a node 
> might try to 
> > > > > > supply a bogus Registration Reply to a mobile node 
> that causes 
> > > > > > the mobile node to act as if its Registration Reply were 
> > > > > > rejected.  This might happen when, in fact, a Registration 
> > > > > > Reply showing acceptance of the registration might soon be 
> > > > > > received by the mobile node."
> > > > > 
> > > > > Yes.
> > > > > 
> > > > > > Based on the past email discussion we had, it was 
> determined 
> > > > > > that the information supplied by the HA is not getting 
> > > > > > invalidated by the FA due to the order of MN-HA 
> Auth extension 
> > > > > > in the Registration Reply. Hence, this whole 
> paragraph was not 
> > > > > > applicable.
> > > > > 
> > > > > I don't see this at all. Section 3.2 suggests that 
> the FA change 
> > > > > the response code value, which would definitely 
> invalidate the 
> > > > > MN-HA Auth extension from the HA. I don't see how we can 
> > > > > eliminate the text above.
> > > > > 
> > > > [JB] Can you quote the exact text of interest in section 3.2? I 
> > > > will look at that and if necessary we can include the text.
> > > 
> > > The text I'm thinking of is the following:
> > > 
> > >                                        "... Also, the 
> Foreign Agent
> > >    SHOULD NOT reject any Registration Reply message 
> coming from the
> > >    Home Agent that does not include the Challenge 
> Extension.  If the
> > >    Challenge Extension is present in the Registration 
> Reply, it MUST
> > >    be the same Challenge value that was included in the 
> Registration
> > >    Request.  If the Challenge value differs in the Registration
> > >    Reply received from the Home Agent, the Foreign Agent 
> MUST reject
> > >    the Registration Request and change the status in the
> > >    Registration Reply to the Code value MISSING_CHALLENGE (see
> > >    section 10)."
> > > 
> > [JB] I would think that the Registration Reply sent to the 
> mobile node 
> > is generated by the FA with the appropriate error-code and 
> not really 
> > relayed what it received from the HA as indicated in the 
> current text. 
> > We can change the current text to reflect this point. What 
> you think?
> 
> That seems to me to be essencially rejecting the Registration 
> Reply coming from the Home Agent, contrary to what section 
> 3.2 currently says. Your're then proposing to change the 
> current mechanism in order to be able to remove a warning 
> text from the draft. I don't think that's a good idea, 
> necessarily. I'd be most comfortable with not changing the 
> mechanism and keeping the text from the original draft in there.
> 
[JB] I am not proposing to change the mechanism discussed in section 3.2.
The text pointed out by you basically deals with sending MISSING_CHALLENGE
instead of relaying the Registration Reply received from the HA. This is the
case where the Registration Reply contains the challenge value different
from the one sent in the Registration Request. I thought you see problem
here since the status code is changed by the FA. 

> 	Henrik

---

From: Henrik Levkowetz <[email-masked]>
Date: Tue, 14 Oct 2003 23:23:51 +0200

> here since the status code is changed by the FA. 

Well, currently the mechanism is to forward the reg. reply from
from the HA, but changing the response code. You propose *not* to
forward the reply from the HA, and instead generate a new reply
from the FA only.

That could potentially break a lot of current implementations,
where the MN relies on getting supplementary information
from the HA, possibly in vendor-specific extensions.

I don't think we should go down that road.

	Henrik