Subject: RE: Kuntal's comments on the split document (was: Re: [Mip6]Conclusion of the consensus call relatedtothebootstrapping I-Ds)

From: "Chowdhury, Kuntal" <[email-masked]>
Date: Tue, 22 Aug 2006 20:19:45 -0400

I think there needs to be ways described in IETF documents for each
scenario. Otherwise, the SDOs will have,

1. No clue what to do, or
2. Will have clue, but each one will invent new ways

We should at least try to avoid that situation.

-Kuntal

> -----Original Message-----
> From: Tsirtsis, George [mailto:[email-masked]]
> Sent: Tuesday, August 22, 2006 6:16 PM
> To: Chowdhury, Kuntal; James Kempf; Alper Yegin; Basavaraj Patil;
> [email-masked]
> Subject: RE: Kuntal's comments on the split document (was: Re:
> [Mip6]Conclusion of the consensus call relatedtothebootstrapping I-Ds)
> 
> I have not followed this discussion from the beginning so my apologies
> if this has been discussed before.
> 
> IMHO, the problem with both the split and integrated documents is that
> they are more system design documents than protocol specifications.
> 
> I think the WG correctly decided to standardize the DHCP-option of the
> integrated document separately since this is the protocol part.
> The rest of the document defines a way to use the DHCP-option together
> with other IETF "tools" to build a system. The split document does the
> same thing so, if there is a protocol extension to be standardized
> (e.g., DNS Update mobility option) it needs to be taken out and be
> standardized.
> 
[KC>] Agree, only if _both_ the documents are made informational.

> Let me remind everyone that the IETF does not build
> systems/architectures unless absolutely necessary and in this case it
is
> not necessary since one can come up with many different ways of using
> several IETF protocols to bootstrap MIP, all of which are valid.
> 
[KC>] We should avoid this if possible. No one benefits from a
fragmented solution space. So, a solution description in an IETF
document is the correct way to go.

> The "system description" parts of the split/integrated documents can
> then become whatever; it does not really matter since the notion of
> "standards track" in the IETF does not apply to systems. As far as I
am
> concerned, if they need to be standardized at all, they need to be
> standardized in an SDO otherwise informational or BCP can work too.
> 
[KC>] There are some exceptions where a framework document in IETF is
also standards track. I don't agree that how to knit the pieces of the
puzzle together should be left entirely to the SDOs. 

> Regards
> George
> 
> > -----Original Message-----
> > From: Chowdhury, Kuntal [mailto:[email-masked]]
> > Sent: Tuesday, August 22, 2006 6:27 PM
> > To: James Kempf; Alper Yegin; Basavaraj Patil; [email-masked]
> > Subject: RE: Kuntal's comments on the split document (was: Re:
> > [Mip6]Conclusion of the consensus call relatedtothebootstrapping
I-Ds)
> >
> >
> >
> > > -----Original Message-----
> > > From: James Kempf [mailto:[email-masked]]
> > > Sent: Tuesday, August 22, 2006 3:37 PM
> > > To: Chowdhury, Kuntal; Alper Yegin; Basavaraj Patil; [email-masked]
> > > Subject: Kuntal's comments on the split document (was: Re: [Mip6]
> > > Conclusion of the consensus call relatedtothebootstrapping I-Ds)
> > >
> > > Alright. If you want to discuss the split document then let's do
it
> > (note
> > > change in thread header).
> > >
> > > [KC>] Which part of my statement you found to be "emotional"? Is
it
> > the
> > > "rather useless" part? In my opinion, the split scenario solution
> > > document has some things that are totally out of scope of mip6
> > > bootstrapping (e.g. the dynamic DNS update). Moreover, the HA
> > > bootstrapping is based on DNS query which has security issues.
> Anybody
> > > in the public internet can discover operator's HAs. This is a
> security
> > > hole that the split solution introduces. These are NOT emotional
> > > statements :-). I am just expressing how I feel about the split
> > solution
> > > document, that's all.
> > >
> > > jak>> These are your opinions, and I would say they are rather
> > emotionally
> > > expressed (my opinion, of course).
> > >
> > > jak>> The goals of the split document are different from the
> > intergrated
> > > document. The split document is primarily for enterprises and for
> > > businesses
> > > that have as their primary business providing mobility service
only
> > (hence
> > > the name). Since such businesses are new, they are likely to be
> > > entrepreneurial. They're not going to have the time or resources
to
> > run
> > > around to various different SDOs and try to force their solutions
to
> > get
> > > locked into the standards. The split solution is designed to
provide
> > them
> > > with interoperability. It is possible for integrated wireless
> service
> > > providers to use the split solution, of course, possibly as an
> > additional
> > > revenue generator for providing mobility service to customers that
> use
> > a
> > > different access network provider.
> > >
> > [KC>] What you describe above is the scope of the split document.
The
> > scope is unique, understood. But that does not automatically justify
a
> > standards track RFC for the solution document. What we have is a
split
> > scenario solution framework document _using_ IKEv2, DNS etc. So, are
> you
> > OK to make the split solution I-D an informational RFC?
> >
> > > jak>> Regarding the security issues of DNS, we've been through
this
> > issue
> > > a
> > > number of times, the draft was reviewed by SAAG (we have yet to
> > respond)
> > > and
> > > there was nothing said about it, so I am puzzled why you are
raising
> > this
> > > canard again. We recently had a good (and I might add
nonemotional)
> > > discussion on this list about using anycast, initiated by
> Jean-Marie,
> > and
> > > I've drafted some text up that will allow anycast addresses to be
> used
> > in
> > > DNS SRV RRs instead of the unicast addresses of the HAs, based on
> > > Francis's
> > > draft, and sent the text to Gerardo (he's on vacation at the
> moment).
> > This
> > > should provide some moderate protection from DoS, but it will not
> > protect
> > > completely, just as the DHCP solution won't. As I've pointed out
in
> > the
> > > past, as soon as you release the address of a server to an end
host,
> > > regardless of how it is done, all bets are off. What the end host
> does
> > > with
> > > that address is completely out of your control, and if the end
host
> is
> > > infected with malware, you can be sure somebody's botnet will get
> the
> > > address. Or are you proposing some enhancement to the DHCP based
> > solution
> > > that will make it impossible for malware to grab a home agent's
> > address?
> > >
> > [KC>] There is a clear difference between the way HA address is
> > discovered in the split solution and in the integrated solution. The
> HA
> > address is _assigned_ to the MN in the integrated solution by the
Home
> > AAA server. This ONLY happens once the MN passes authentication. So,
> the
> > chances of giving away the HA address to totally unknown entities in
> > this case is next to none. In case of split scenario, the HAs are
> > totally exposed to anyone with good or bad intention. Anyone with an
> IP
> > connection can send DNS queries to get any MSP's HA addresses and
then
> > launch DoS attacks from his/her basement.
> >
> > It is true that once the HA address is given to an entity, if that
> > entity is compromised, the HA address can get out to some bad guys.
> But
> > it is not likely to happen too often. This type of security threat
is
> > generic and not specific to mip6 bootstrapping, IMHO. If the
> > entity/device is compromised, other things like root-key, username,
> any
> > other cached data will also be revealed. So, it is a generic issue.
> >
> > In case of split scenario, the risk of giving away the HA address to
> bad
> > guys is always there. So, the solution doesn't seem to be deployable
> in
> > public wireless networks.
> >
> > > > HL prefix etc. Integrated scenario is likely to be widely
> deployed,
> > > > where as the split scenario doesn't even have any buyer.
> > > >
> > > > jak>> I think you mean draft-jang will be widely deployed. As I
> > recall
> > > > someone posted email a while back saying that there was no plan
by
> > any
> > > > other
> > > > SDO to adopt the integrated draft as is, just the two draft-jang
> > DHCP
> > > > enhancements.
> > > >
> > > [KC>] Unfortunately, here you are making your argument based on
some
> > > rumor that you heard about real SDO requirements. Please use
> official
> > > liaison channels to confirm SDO requirements before posting
comments
> > on
> > > the mailing list.
> > >
> > > jak>> OK. Would any of our liasons like to comment on this? Is the
> > system
> > > architecture described in the integrated draft what your SDO is
> > planning
> > > on
> > > standardizing?
> > >
> > > > So, if you want to go down this path, we will end up making both
> the
> > > > documents informational. If not both of them should remain
> standards
> > > > track.
> > > >
> > > > jak>> We're not discussing the split draft here. If you want to
> > > propose
> > > > changing it, then start a separate thread.
> > > >
> > > [KC>] We need to discuss how useful the split scenario draft is.
> Also
> > to
> > > be fair, we need to make a decision about informational vs.
> standards
> > > track suitability for _both_ the documents if that's what the WG
> ends
> > up
> > > deciding. That's what I meant to say here.
> > >
> > > jak>> Then why didn't you start a separate thread on it? This is
> basic
> > > IETF
> > > courtesy. Kuntal, you've been around IETF long enough to know
these
> > kinds
> > > of
> > > things.
> > >
> > [KC>] OK, I apologize for raising the issues with the split
solutions
> > I-D late in the game. James, you did not raise all the issues that
you
> > had with the integrated I-D until now. You have been around in IETF
> more
> > than I have been....
> >
> >
> > >             jak
> > >
> >
> >
> > "This email message and any attachments are confidential information
> of
> > Starent Networks, Corp. The information transmitted may not be used
to
> > create or change any contractual obligations of Starent Networks,
> Corp.
> > Any review, retransmission, dissemination or other use of, or taking
> of
> > any action in reliance upon this e-mail and its attachments by
persons
> or
> > entities other than the intended recipient is prohibited. If you are
> not
> > the intended recipient, please notify the sender immediately -- by
> > replying to this message or by sending an email to
> > [email-masked] -- and destroy all copies of this
> message
> > and any attachments without reading or disclosing their contents.
> Thank
> > you."
> >
> > _______________________________________________
> > Mip6 mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/mip6

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