Re: Remaining open issues for RFC-2401bis

["Mohan Parthasarathy" <mohanp@sbcglobal.net>]

 > >>  >  >
> >>  >>
> >>  >>  >>>>> "VPNC" == VPNC  <Paul> writes:
> >>  >>      VPNC> No, we don't. We have ways of encoding the display name and
> >>  >>      VPNC> the coments, but *not* the address itself (called the
> >>  >>      VPNC> "addr-spec"). RFC 822 and 2822 are completely clear on this.
> >>  >>
> >>  >>    Ah, good point.
> >>  >>
> >>  >>      >> 2) we could agree to permit UTF-8 in RFC822_ADDR.
> >>  >>
> >>  >>      VPNC> Doing so and hoping that the Applications Area Directors don't
> >>  >>      VPNC> barf is like
> >>  >>
> >>  >>    Fine. Point made.
> >>  >>    So, we need an identifier that can carry UTF-8, is known to carry
> >>  >>  UTF-8, and isn't ID_KEY_ID.
> >>  >>
> >>  >I hope this does not preclude ID_KEY_ID from carrying UTF-8 in an
> >>  >opaque way. I think this is what Paul Koning mentioned in an earlier mail.
> >>  >
> >>
> >>  For the reasons cited earlier, I think it is a bad idea to carry
> >>  structured data like UTF-8 in what is described as an opaque octet
> >>  string. there is no reason to assume that there will be management
> >>  interfaces to facilitate entry of the data in a compatible fashion,
> >>  even without the encoding options that Paul has pointed out.
> >>
> >ID_KEY_ID is defined as an opaque octet stream and UTF-8 can be
> >carried as an opque stream of bytes where the two ends do a "memcmp" of the
> >opaque byte stream to match on the ID contents. Why is this not possible ?
> >As i mentioned in the other mail, this content may be dynamically generated.
> >Perhaps we need a different ID to carry structured data like UTF8 that will be
> >created through mangement interfaces. At least, that is what i understood from
> >the emails on this topic.
> 
> My comments on management interfaces for this ID type get at the 
> heart of the problem, and I'm a bit disappointed that your messages 
> seem to keep ignoring that. This discussion has never been about how 
> to perform a comparison of the data; it is about whether users and 
> admins interacting with different vendor products will have 
> appropriate management interfaces to enter the data that is sent and 
> that forms the basis for checking, IF the description of the 
> semantics of the data were as stated in IKEv2.
> 
I do see your point about how if we restrict the ID_KEY_ID to account names
/login names as stated in IKEv2 will make the interactions with various
vendor products easier. But the other point that was made in this thread is
that ID_KEY_ID also has been used to select pre-shared key and it can
carry a opaque stream of bytes. The data for ID_KEY_ID itself may be
configured using some management interface or dynamically generated.
For the dynamically generated case, there is no issue  i suppose. But if
we use ID_KEY_ID for values entered through management interfaces
also, then the issue of "how different products would support this" comes up.
At least it looks like we need flexibility in one case (dynamic) and restriction
in another case (configuration through UI) to make configuration easier.
I can see how it can become a nightmare configuring product from Vendor X
using ASCII and configuring product from Vendor Y using hex for making
it communicate with each other. But at least there is a possiblity that you can get
this right by doing the right conversion. But if you restrict it to use only login names,
then the flexibility is lost. I know at least that 3GPP2 uses the ID_KEY_ID  that is
generated dynamically and communicated using RADIUS. There may be others
e.g PANA that will use ID_KEY_ID to carry session ids.

> Nonetheless, I agree that a good way to resolve this is to change the 
> IKE text back to the v1 version, that makes no mention of account IDs 
> etc.
> 
Will RFC 2401bis also reflect the same ?

> Then, if the WG wants, a separate ID type can be created to carriage 
> of account info such as login IDs.
> 
Sounds good to me.

thanks
mohan


> Steve