A question about IPSec implementation..
Hi, all:
Recently I found a paragraph of codes about IPSec replay prevention
that confused me a lot. Could you shed some light on me?
line 2370 to line 2407 in ipsec.c deal with the replay window update.
/if (seq > replay->lastseq) {
/* seq is larger than lastseq. */
diff = seq - replay->lastseq;
/* new larger sequence number */
if (diff < wsizeb) {
/* In window */
/* set bit for this packet */
vshiftl(replay->bitmap, diff, replay->wsize);
replay->bitmap[frlast] |= 1;
} else {
/* this packet has a "way larger" */
bzero(replay->bitmap, replay->wsize);
replay->bitmap[frlast] = 1;
}
replay->lastseq = seq;
/* larger is good */
} else {
./
When the receiving sequence number larger than the maintained last
largest one, it will do /vshiftl/ and then /switch on the last bit of
the bitmap/. What I am wondering here is: is the current receiving
sequence number necessarily the last bit after doing /vshiftl/? Why to
do /vshiftl/?
Thanks for your time.
BR,
Yi-Wen
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Questions about PF_KEY interface
Dear all: I found there are two directories about PF_KEY interface: netkey and netipsec under $FreeBSD src$\sys\. Looking into the makefile, the one that is currently used and built in is netkey. However, I am wondering what's the purpose for netipsec? Besides, the handling for the global variable "regtree", which is used for key registery, in netipsec seems more proper to me. For example, when a key is needed to register, the static function, key_register(), which is defined in [netkey/netipsec]/key.c, will be called. However, in netkey/key.c, key_register() will not call mtx_lock before the operation of the global variable, regtree. On the other hand, in netipsec/key.c, key_register() will mtx_lock. In my opinion, I think the latter should be correct since there may be various processes to call the function. Without the protection, race condition will occur! Many thanks. blue ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Questions about PF_KEY interface
Hi, Thanks for your kindly and quick response :> I still have some questions, though... VANHULLEBUS Yvan wrote: On Mon, Jun 25, 2007 at 02:50:08PM +0800, blue wrote: Dear all: Hi. I found there are two directories about PF_KEY interface: netkey and netipsec under $FreeBSD src$\sys\. Looking into the makefile, the one that is currently used and built in is netkey. However, I am wondering what's the purpose for netipsec? netkey is used if you compile with IPSEC (KAME's stack). netipsec is used if you compile with FAST_IPSEC. I have read the manual page for fast_ipsec and ipsec. However, the man page for fast_ipsec on FreeBSD-6.1Release said currently fast_ipsec does not support IPv6. However, I thought it could properly deal with IPv6 packets after tracing code. Could fast_ipsec support IPv6? Another problem is: if the only difference between fast_ipsec and ipsec is about crypto acceleration, why fast_ipsec needs to modify a bunch of files (including ip6_input, ip6_output, ip6_forward, ..., etc.), not only the encap/decap part? Besides, the handling for the global variable "regtree", which is used for key registery, in netipsec seems more proper to me. For example, when a key is needed to register, the static function, key_register(), which is defined in [netkey/netipsec]/key.c, will be called. However, in netkey/key.c, key_register() will not call mtx_lock before the operation of the global variable, regtree. On the other hand, in netipsec/key.c, key_register() will mtx_lock. In my opinion, I think the latter should be correct since there may be various processes to call the function. Without the protection, race condition will occur! KAME's IPSec stack is still giant locked, so doesn't needs more fined locking. FAST_IPSEC used fined grain locking. The function, key_output(), which is defined in netkey\keysock.c, does not lock Giant before key_parse(). According to the comments (see below), maybe the author wants to lock Giant before the operation? However, does it mean currently it may have race condition problem? / /*XXX giant lock*/ s = splnet(); error = key_parse(m, so); m = NULL; splx(s);/ KAME's stack will probably be removed in the future (for 7.0 ?) thanks George V. Neville-Neil's work to provide all KAME's stack features on FAST_IPSEC. Do you mean FAST_IPSEC feature will be embedded in FreeBSD-7.0 or later version instead of IPSEC? Yvan. Thanks for your help :> Best regards, blue ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Some implementation problems about IPsec
Dear all:
I am tracing the codes for the implementation for IPsec recently. I have
two problems here about the implementation:
1. In ip6_input.c, before handing the packet to the next protocol
handler after processing of IPv6 headers,
#ifdef IPSEC
/*
* enforce IPsec policy checking if we are seeing last header.
* note that we do not visit this with protocols with pcb layer
* code - like udp/tcp/raw ip.
*/
if ((inet6sw[ip6_protox[nxt]].pr_flags & PR_LASTHDR) != 0 &&
ipsec6_in_reject(m, NULL)) {
ipsec6stat.in_polvio++;
goto bad;
}
#endif
Why needs to do ipsec6_in_reject() here for some specific "LASTHDER"
protocols, such as icmp? Why not all the packets need the check?
2. What is the real meaning for the flags M_AUTHIPHDR, M_AUTHIPDGM, and
M_DECRYPTED? At the beginning, I thought the mbuf carrying either one of
the flags would represent it had processed by IPsec stack. However, in
KAME implementation, ah_input and ah6_input will unset the flag after an
AH tunneled packet has been passed the authentication. While ESP is the
case, once M_DECRYPTED flag is set, it would never be unset. On the
other hand, in FAST_IPSEC, which is another different IPsec
implementation on FreeBSD, the flags are never unset, and also another
flag named M_IPSEC is defined as M_AUTHIPHDR | M_AUTHIPDGM |
M_DECRYPTED. I am confused by the inconsistent usage.
Many Thanks.
Susan
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Current round of IPsec checkins complete...
Hi,
What is the main enhancement for the commit?
Tracing back the discussion, It is all about NAT-T?
How is the FAST_IPSEC for IPv6?
Thanks.
BR,
Susan
Norberto Meijome wrote:
On Mon, 2 Jul 2007 17:31:05 +0200
VANHULLEBUS Yvan <[EMAIL PROTECTED]> wrote:
http://vanhu.free.fr/FreeBSD/patch-natt-freebsd6-.diff
applies to STABLE, and currently does not needs update. It may apply
to -CURRENT, but won't compile cleanly.
great, thanks Yvan , will try soon.
_
{Beto|Norberto|Numard} Meijome
Real Programmers don't comment their code. If it was hard to write, it should
be hard to understand and even harder to modify.
I speak for myself, not my employer. Contents may be hot. Slippery when wet.
Reading disclaimers makes you go blind. Writing them is worse. You have been
Warned.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Ipsec - PF_KEY and set_policy
As far as I know, setkey is used for IPsec SP and SA configuration. ipsec_set_policy() could transfer a string to "policy request", which is defined in RFC 2367 PF_KEY. Internally, setkey() will call ipsec_set_policy() to construct the message then send it down to the kernel. However, ipsec_set_policy() is used only for SP, not SA. blue aditya kiran wrote: Hi, I was just trying to understand PF_KEY interface for ipsec settings. So, setkey uses it to do that. but i could find another system call - ipsec_set_policy. Could any body let me know why there are two interfaces to configure ipsec? Thanks, Aditya ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
IPv6 IPsec tunnel configuration
Dear all: I want to set up the gif tunnel for IPv6 IPsec as the Freebsd Handbook http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/ipsec.html "VPN over IPsec" suggested for IPv4. However, I could not configure the local IP address via "ifconfig gif0 inet6 address>", ifconfig will complain the parameters are invalid! Is there any other way to configure the IPv6 IPsec tunnel? Thanks. BR, Yi-Wen ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: IPv6 IPsec tunnel configuration
Dear Eric: Thanks for your reply, but this page explains how to setup configured tunnel for IPv6 packets over IPv4 network. I need a gif0 interface whose endpoints are both IPv6 address, and the display should be like: gif0: flags=8051 mtu 1280 tunnel inet aa:bb:cc:dd::ee --> ww:xx:yy::zz inet6 11:22:33:44::11 --> 55:66:77:88::55 netmask 0x But currently I could not succeed in making the inner addresses. Eric F Crist wrote: On Jul 26, 2007, at 8:11 PMJul 26, 2007, blue wrote: Dear all: I want to set up the gif tunnel for IPv6 IPsec as the Freebsd Handbook http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/ ipsec.html "VPN over IPsec" suggested for IPv4. However, I could not configure the local IP address via "ifconfig gif0 inet6 IPv6 address>", ifconfig will complain the parameters are invalid! Is there any other way to configure the IPv6 IPsec tunnel? Thanks. Take a look here and see if this helps you at all: https://www.secure-computing.net/wiki/index.php/IPv6_on_FreeBSD_6.2 - Eric F Crist Secure Computing Networks ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
SADB_X_SPDFLUSH message handling for latest version of IPsec
Hi, all: Recently I found the behavior for the command "setkey -FP" is quite different for the latest version IPsec (known as FAST_IPSEC before). Before the command would erase all the existed SP entries; currently the command would not. After digging the codes, I found the state of the SP entries will be set as IPSEC_SPSTATE_DEAD, but the entries will not be unlink from the SPD. Why needs to keep the entry in SPD? Is there any special purpose? Without the removal, it's hard to tell whether the SP entry still takes effect since "setkey -PD" will not show its status. On the other hand, SA is like usual, once the "setkey -F" is typed in, the SA entries will be erased right away. Thanks. BR, blue ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: SADB_X_SPDFLUSH message handling for latest version of IPsec
[EMAIL PROTECTED] wrote:
At Thu, 26 Jul 2007 11:13:53 +0800,
blue wrote:
Hi, all:
Recently I found the behavior for the command "setkey -FP" is quite
different for the latest version IPsec (known as FAST_IPSEC before).
Before the command would erase all the existed SP entries; currently the
command would not. After digging the codes, I found the state of the SP
entries will be set as IPSEC_SPSTATE_DEAD, but the entries will not be
unlink from the SPD. Why needs to keep the entry in SPD? Is there any
special purpose? Without the removal, it's hard to tell whether the SP
entry still takes effect since "setkey -PD" will not show its status. On
the other hand, SA is like usual, once the "setkey -F" is typed in, the
SA entries will be erased right away.
Can you give an example of this? On my test systems this works for
me:
dut2 ? cat /etc/ipsec.conf
spdadd 10.0.0.1/32 10.0.0.2/32 any -P out ipsec esp/tunnel/10.0.0.1-10.0.0.2/require;
spdadd 10.0.0.2/32 10.0.0.1/32 any -P in ipsec
esp/tunnel/10.0.0.2-10.0.0.1/require;
add 10.0.0.1 10.0.0.2 esp 0x1000 -E des-cbc 0x3ffe05014819;
dut2 ? setkey -f !$
setkey -f /etc/ipsec.conf
dut2 ? setkey -DP
10.0.0.2[any] 10.0.0.1[any] any
in ipsec
esp/tunnel/10.0.0.2-10.0.0.1/require
spid=13 seq=1 pid=72816
refcnt=1
10.0.0.1[any] 10.0.0.2[any] any
out ipsec
esp/tunnel/10.0.0.1-10.0.0.2/require
spid=12 seq=0 pid=72816
refcnt=1
dut2 ? setkey -D
10.0.0.1 10.0.0.2
esp mode=any spi=4096(0x1000) reqid=0(0x)
E: des-cbc 3ffe0501 4819
seq=0x replay=0 flags=0x0040 state=mature
created: Jul 22 23:10:07 2007 current: Jul 22 23:10:12 2007
diff: 5(s) hard: 0(s) soft: 0(s)
last: hard: 0(s) soft: 0(s)
current: 0(bytes) hard: 0(bytes) soft: 0(bytes)
allocated: 0hard: 0 soft: 0
sadb_seq=0 pid=72817 refcnt=1
dut2 ? setkey -FP
dut2 ? setkey -DP
No SPD entries.
dut2 ?
Best,
George
Hi,
I was tracing the codes so had the conclusion. in key_spdflush() in
key.c, the loop
for (dir = 0; dir < IPSEC_DIR_MAX; dir++) {
SPTREE_LOCK();
LIST_FOREACH(sp, &sptree[dir], chain)
sp->state = IPSEC_SPSTATE_DEAD;
SPTREE_UNLOCK();
}
only sets policy entry's status as DEAD, but not remove it from the SPD.
On the other hand, in KAME implementation (known as IPSEC in previous
FreeBSD version), the SP entry will be removed.
for (sp = TAILQ_FIRST(&sptailq); sp; sp = nextsp) {
nextsp = TAILQ_NEXT(sp, tailq);
if (sp->persist)
continue;
if (sp->state == IPSEC_SPSTATE_DEAD)
continue;
key_sp_dead(sp);
key_sp_unlink(sp);
sp = NULL;
}
Thanks.
BR,
blue
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
IPsec AH tunneling pakcet mis-handling?
Dear all:
I do not know the purpose of the following codes in the very beginning
in ip6_input():
#ifdef IPSEC
/*
* should the inner packet be considered authentic?
* see comment in ah4_input().
*/
if (m) {
m->m_flags &= ~M_AUTHIPHDR;
m->m_flags &= ~M_AUTHIPDGM;
}
#endif
Consider the case: a packet is encrypted as AH tunneled, and FreeBSD is
the end point of the tunnel. After it tore off the outer IPv6 header,
the mbuf will be inserted to NETISR again. Then ip6_forward() will be
called again to process the packet. However, in ipsec6_in_reject(), the
packet's source and destination will match the SP entry. Since
ip6_input() has truned off the flag M_AUTHIPHDR and M_AUTHIPDGM, the
packet will be dropped.
I don't think with the codes AH tunnel could work properly.
Best regards,
Yi-Wen
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
A and AAAA DNS query process in getaddrinfo()?
Dear all: When looking into kame-20070801-freebsd54-snap, the function, _dns_getaddrinfo(), defined in getaddrinfo.c, will check if the device gets any IPv4/global IPv6 address before sending out any A/ query by calling addrconfig() if the user does not specify the family type (AF_UNSPEC). However, FreeBSD-CURRENT (known is going to be FreeBSD7.0), does not do the process. Do we need to do the same check before sending out the A/ query? Thanks. BR, Yi-Wen ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: A and AAAA DNS query process in getaddrinfo()?
Max Laier wrote:
On Friday 10 August 2007, JINMEI Tatuya / 神明達哉 wrote:
At Fri, 10 Aug 2007 11:52:09 +0800,
blue <[EMAIL PROTECTED]> wrote:
When looking into kame-20070801-freebsd54-snap, the function,
_dns_getaddrinfo(), defined in getaddrinfo.c, will check if the
device gets any IPv4/global IPv6 address before sending out any
A/ query by calling addrconfig() if the user does not specify the
family type (AF_UNSPEC). However, FreeBSD-CURRENT (known is going to
be FreeBSD7.0), does not do the process.
Do we need to do the same check before sending out the A/ query?
I'm afraid just asking this question without providing a context could
be misleading. I guess this is a continuation of a thread of the
[EMAIL PROTECTED] list:
ftp://ftp.kame.net/pub/mail-list/snap-users/9541
ftp://ftp.kame.net/pub/mail-list/snap-users/9544
If so, we should discuss this with the understanding of why KAME-snap
version behaves that way, specifically referring to Section 3
(especially 3.4.1) of this document:
http://v6fix.net/docs/wide-draft-v6fix.en
We (KAME) thought the behavior was reasonable but we were also afraid
this might be too experimental to incorporate to *BSD release
versions at that time. That's why it's not in the FreeBSD repository.
I'm interested in what others think on this. If others think this
feature is reasonable, too, and want it, I'm happy to commit the
change to the FreeBSD repository.
I agree with the reasoning in the document you reference above.
getaddrinfo is a convenience resolver and thus it's a good thing to
return reasonable defaults. Not returning when there are no IPv6
addresses around seems reasonable to me. I'm not sure it's a good idea
to go the other way (i.e. not sending A queries when there are no IPv4
addresses), however.
Although DNS resolver may lead to some delay or misbehavior of the upper
application, I think that would be caller's resposibility to decide
which result it would like to use. I am not so sure about the check in
KAME implementation, in getaddrinfo.c:
_dns_getaddrinfo(
void*rv,
void*cb_data,
va_list ap
){
.
switch (pai->ai_family) {
case AF_UNSPEC:
qp = &q;
buf_current = buf;
/*
* Since queries for can cause unexpected misbehavior,
* we first send A queries. Note that the query ordering
* is independent from the ordering of the resulting addresses
* returned by getaddrinfo().
*/
if (addrconfig(AF_INET, ac)) {
qp->name = hostname;
qp->qclass = C_IN;
qp->qtype = T_A;
qp->answer = buf_current->buf;
qp->anslen = sizeof(buf_current->buf);
if (addrconfig(AF_INET6, ac)) {
qp->next = &q2;
buf_current = buf2;
qp = &q2;
}
}
if (addrconfig(AF_INET6, ac)) {
qp->name = hostname;
qp->qclass = C_IN;
qp->qtype = T_;
qp->answer = buf_current->buf;
qp->anslen = sizeof(buf_current->buf);
}
break;
case AF_INET:
q.name = hostname;
q.qclass = C_IN;
q.qtype = T_A;
q.answer = buf->buf;
q.anslen = sizeof(buf->buf);
break;
case AF_INET6:
q.name = hostname;
q.qclass = C_IN;
q.qtype = T_;
q.answer = buf->buf;
q.anslen = sizeof(buf->buf);
break;
default:
free(buf);
free(buf2);
return NS_UNAVAIL;
}
.
}
Why the check for avilable IPv4/IPv6 address, addrconfig(), only applies
when the hints' family type is AF_UNSPEC? I think if delaying the upper
application is a concern, the check should be applied no matter what
family type it is.
Thanks.
Best regards,
Yi-Wen
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: A and AAAA DNS query process in getaddrinfo()?
JINMEI Tatuya / wrote: At Fri, 10 Aug 2007 13:45:46 +0800, blue <[EMAIL PROTECTED]> wrote: Although DNS resolver may lead to some delay or misbehavior of the upper application, I think that would be caller's resposibility to decide which result it would like to use. I am not so sure about the check in KAME implementation, in getaddrinfo.c: (snip) Why the check for avilable IPv4/IPv6 address, addrconfig(), only applies when the hints' family type is AF_UNSPEC? I think if delaying the upper application is a concern, the check should be applied no matter what family type it is. I thought the v6fix document provided sufficient background to answer these questions, but in case it didn't I'm going to rephrase the points: - ideally, we'd not want to introduce the special behavior; as you indicated above, the ideal behavior for getaddrinfo() called with AF_UNSPEC would be to return all possible IPv4 and IPv6 addresses via A and queries. - unfortunately, however, a dual stack application running on IPv4-only node could suffer from various problems due to misbehaving DNS servers if the underlying resolver sends out queries. Note that the most typical behavior for such dual stack applications is to call getaddrinfo() with AF_UNSPEC. - the specific behavior of the KAME-snap version of getaddrinfo() is a workaround to mitigate the problem in the conflicting situation, yet still being compliant to the API specification. - since this is a workaround, we'd not want to do the same ugly hack for the less common case of getaddrinfo() called with AF_INET6. Also, in this case the node without an effective IPv6 address would not be able to make any IPv6 communication regardless of the getaddrinfo() results or how long it takes, and the application doesn't have any alternative network protocol unlike the case of AF_UNSPEC, so introducing the same hack doesn't actually help the application. - so, comparison between the AF_UNSPEC case and the AF_INET6/AF_INET case in terms of superficial consistency doesn't really make sense. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. [EMAIL PROTECTED] Dear Jinmei: Thanks for your detailed explanation, and I have a deeper insight into the problem that IPv4/IPv6 dual stack may introduce to current applications. Best regards, Yi-Wen ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
infinite loop in esp6_ctlinput()?
Dear all: When receiving a "packet too big" ICMP error message, FreeBSD will call the ctlinput() function of the upper protocol. If the preceding packet is an ESP IPv6 packet, then FreeBSD will call esp6_ctlinput(). In esp6_ctlinput(), pfctlinput2() will be executed to traverse all possible upper protocols, and call their registered ctlinput() function. However, that would call esp6_ctlinput() again since ESP is one of the upper protocols! Then an infinite loop occurs!! After comparing both IPSEC and FAST_IPSEC, the operations are exactly the same. Is it a bug? Best regards, Yi-Wen ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: infinite loop in esp6_ctlinput()?
Since our device adopts the IPsec codes from BSD, our device will have infinite loop after receiving ICMP packet too big message. I am not sure whether BSD itself will have the problem or not (maybe needs further testing). In IPSEC, esp6_ctlinput() still calls pfctlinput2(), which is the root cause of the infinite loop. Best regards, Yi-Wen JINMEI Tatuya / wrote: At Tue, 28 Aug 2007 10:15:31 +0800, blue <[EMAIL PROTECTED]> wrote: When receiving a "packet too big" ICMP error message, FreeBSD will call the ctlinput() function of the upper protocol. If the preceding packet is an ESP IPv6 packet, then FreeBSD will call esp6_ctlinput(). In esp6_ctlinput(), pfctlinput2() will be executed to traverse all possible upper protocols, and call their registered ctlinput() function. However, that would call esp6_ctlinput() again since ESP is one of the upper protocols! Then an infinite loop occurs!! From a quick look at the code, there's a slight difference between the IPSEC (netinet6/esp_input.c) and FAST_IPSEC (netipsec/ipsec_input.c) implementations. I suspect the loop doesn't occur at least for the esp_input.c version. Did you actually see the loop for both, or are you guessing from the code? After comparing both IPSEC and FAST_IPSEC, the operations are exactly the same. Is it a bug? If it actually causes an infinite loop, it's a bug, of course. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. [EMAIL PROTECTED] ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: infinite loop in esp6_ctlinput()?
Hi, According to the GDB backtrace, I think this is what I am talking about. Besides, this would result in infinite loop just by looking at the codes. However, the author seems knowing the problem, too. The comments in esp6_ctlinput() point out: /* * Although pfctlinput2 will call esp6_ctlinput(), there is * no possibility of an infinite loop of function calls, * because we don't pass the inner IPv6 header. */ I am not sure what the description means. The behavior of esp6_ctlinput() is the same in HEAD, too. Best regards, Yi-Wen Bjoern A. Zeeb wrote: On Tue, 28 Aug 2007, blue wrote: Hi, Since our device adopts the IPsec codes from BSD, our device will have infinite loop after receiving ICMP packet too big message. I am not sure whether BSD itself will have the problem or not (maybe needs further testing). In IPSEC, esp6_ctlinput() still calls pfctlinput2(), which is the root cause of the infinite loop. you were talking about IPSEC vs. FAST_IPSEC so I guess you are on RELENG_6 or is that HEAD. Would be helpful to know where exactly (though I guess looking at the code I could find out). Is it the problem reported here[1] that you are describing? /bz [1] http://lists.freebsd.org/pipermail/freebsd-current/2007-August/076478.html Best regards, Yi-Wen JINMEI Tatuya / wrote: At Tue, 28 Aug 2007 10:15:31 +0800, blue <[EMAIL PROTECTED]> wrote: When receiving a "packet too big" ICMP error message, FreeBSD will call the ctlinput() function of the upper protocol. If the preceding packet is an ESP IPv6 packet, then FreeBSD will call esp6_ctlinput(). In esp6_ctlinput(), pfctlinput2() will be executed to traverse all possible upper protocols, and call their registered ctlinput() function. However, that would call esp6_ctlinput() again since ESP is one of the upper protocols! Then an infinite loop occurs!! From a quick look at the code, there's a slight difference between the IPSEC (netinet6/esp_input.c) and FAST_IPSEC (netipsec/ipsec_input.c) implementations. I suspect the loop doesn't occur at least for the esp_input.c version. Did you actually see the loop for both, or are you guessing from the code? After comparing both IPSEC and FAST_IPSEC, the operations are exactly the same. Is it a bug? If it actually causes an infinite loop, it's a bug, of course. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. [EMAIL PROTECTED] ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
ICMP error notification with IPsec in ip6_forward()
Dear all: Recently I am tracing the codes of ip6_forward(), which is defined in ip6_forward.c. My referenced version is FreeBSD Release 6.1. I have the following questions about IPsec operations: (1) lines 489-512 are about the transmission of ICMP Packet Too Big message. Is it necessary here since tunneled packets are already sent out at this point? (2) The location of the packet size examination is not proper. If the packet matches SP, then it will be tunneled without sending out ICMP packet too big error message to the source. (3) Is there any RFC about ICMP notification and IPsec? I am not sure what kind of ICMP error messages should be sent out from the security gateway. For example, is ICMP destination unreachable necessary if the inner destination is unreachable? Or ICMP Redirect packet necessary if the inner destination needs to be redirected? Thanks. Best regards, Yi-Wen ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: IPsec AH tunneling pakcet mis-handling?
Sorry, maybe my words make you confused.
What I meant is "AH tunnel" only, and the code base is FAST_IPSEC, which
is currently IPSEC in FreeBSD-7.0.
BR,
Yi-Wen
Bjoern A. Zeeb wrote:
On Wed, 1 Aug 2007, blue wrote:
Hi,
Dear all:
I do not know the purpose of the following codes in the very
beginning in ip6_input():
#ifdef IPSEC
/*
* should the inner packet be considered authentic?
* see comment in ah4_input().
*/
if (m) {
m->m_flags &= ~M_AUTHIPHDR;
m->m_flags &= ~M_AUTHIPDGM;
}
#endif
Consider the case: a packet is encrypted as AH tunneled, and FreeBSD
is the end point of the tunnel. After it tore off the outer IPv6
header, the mbuf will be inserted to NETISR again. Then ip6_forward()
will be called again to process the packet. However, in
ipsec6_in_reject(), the packet's source and destination will match
the SP entry. Since ip6_input() has truned off the flag M_AUTHIPHDR
and M_AUTHIPDGM, the packet will be dropped.
I don't think with the codes AH tunnel could work properly.
I was pointed at this.
I am a bit unsure about your setup as you are talking about "AH
tunneled" and "encrypted" while at the end it's "AH tunnel" only.
So, are you using IPsec tunnel mode with ESP and AH or just AH, or ...?
Can you describe the setup this would be a problem in detail and maybe
file a PR so this won't be lost again.
We've got other ESP+AH+IPv6 problems pending like PR kern/121373 and I
could look into both at the same time I guess.
PS: I am assuming this was with (Fast) IPsec, not KAME IPsec
implementation? The date was too close to the change, so I thought it
might be better asking;-)
Thanks
/bz
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
[ipsec] KEY_FREESAV() in FreeBSD-Release7.0
Dear all:
About the KEY_FREESAV() in key_checkrequest() in key.c:
line 806:
if (isr->sav != NULL) {
KEY_FREESAV(&isr->sav);
isr->sav = NULL;
}
The codes are only going to free the sav used LAST TIME. For outgoing SA
entries, the reference count will be always 2, instead of 1 like
incoming SA. I thought the proper place to call KEY_FREESAV() should be
ipsec6_output_trans() and ipsec6_output_tunnel() after invoking each
transform's output function. Then the SA will be freed after its usage
rather than being freed if there's next IPsec packet.
If the above condition is accpeted, then key_delsp() in key.c should not
call KEY_FREESAV() in case SA reference count underflow!
BR,
blue
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
[ipsec] bug report: possible memory overwrite for IPv6 IPsec
Dear all:
struct secashead defined in keydb.h line 89:
/* Security Association Data Base */
struct secashead {
LIST_ENTRY(secashead) chain;
struct secasindex saidx;
struct secident *idents;/* source identity */
struct secident *identd;/* destination identity */
/* XXX I don't know how to use them. */
u_int8_t state;/* MATURE or DEAD. */
LIST_HEAD(_satree, secasvar) savtree[SADB_SASTATE_MAX+1];
/* SA chain */
/* The first of this list is newer SA */
struct route sa_route;/* route cache */
};
The last field "sa_route" is "struct route", whose space is not enough
for IPv6 address. However, in ipsec6_output_tunnel() in ipsec_output.c,
the field could possibly be assigned with an IPv6 address.
My suggestion is to enlarge the field as struct route_in6, which could
accommodate both IPv4 and IPv6 address.
BR,
blue
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
[ipsec] Packet Too Big message handling in esp6_ctlinput()
Dear all:
In line 814 to line 843 in esp6_ctlinput(),
if (cmd == PRC_MSGSIZE) {
struct secasvar *sav;
u_int32_t spi;
int valid;
/* check header length before using m_copydata */
if (m->m_pkthdr.len < off + sizeof (struct esp))
return;
m_copydata(m, off + offsetof(struct esp, esp_spi),
sizeof(u_int32_t), (caddr_t) &spi);
/*
* Check to see if we have a valid SA corresponding to
* the address in the ICMP message payload.
*/
sav = KEY_ALLOCSA((union sockaddr_union *)sa,
IPPROTO_ESP, spi);
valid = (sav != NULL);
if (sav)
KEY_FREESAV(&sav);
/* XXX Further validation? */
/*
* Depending on whether the SA is "valid" and
* routing table size (mtudisc_{hi,lo}wat), we will:
* - recalcurate the new MTU and create the
* corresponding routing entry, or
* - ignore the MTU change notification.
*/
icmp6_mtudisc_update(ip6cp, valid);
}
I don't know why ESP needs to take care of ICMP Packet Too Big message
specially since icmp6_mtudisc_update() will be called in
icmp6_notify_error(),
which will already update the PMTU of the host. I think the codes here
could be removed.
BR,
Yi-Wen
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
[FreeBSD6.1-RELEASE]problem about soisconnected() in uipc_socket2.c
Hi,all: I have found a questionable code in soisconnected() function in uipc_socket2.c. In the very beginning, the SOCK_LOCK() would lock the socket. However, in line 127, it unlocks socket. I am wondering that SOCK_UNLOCK() should be called until all the socket's parameters are done. In my opinion, it should be located right before ACCEPT_UNLOCK(). Best regards, blue ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
T/TCP in FreeBSD6.1-RELEASE
Hi, All: Why has FreeBSD6.1-RELEASE removed T/TCP extensions? The TCP options of "connection count" suggested in RFC 1379 no longer exists in the version. However, I could still see some "T/TCP logic" in functions such as tcp_input() or tcp_output(). Shouldn't these logic be removed, either? Best regards, blue ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
[freeBSD-6.1RELEASE] wonderings about function tcp_input()
Hi, all:
I have a question about line 1765 to 1776 in tcp_input():
/*
* If the ACK bit is off: if in SYN-RECEIVED state or SENDSYN
* flag is on (half-synchronized state), then queue data for
* later processing; else drop segment and return.
*/
if ((thflags & TH_ACK) == 0) {
if (tp->t_state == TCPS_SYN_RECEIVED ||
(tp->t_flags & TF_NEEDSYN))
goto step6;
else
goto drop;
}
My question is: if we are currently in TCPS_SYN_RECEIVED state, why does
a segment without ACK bother? Why we need to store the segment and
process it? Without considering T/TCP, the code should be:
if ((thflags & TH_ACK) == 0) {
goto drop;
}
Best regards,
blue
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
[FreeBSD-6.1RELEASE] tcp in TIME_WAIT state
Hi, all: In function tcp_timewait(), which will be called when receiving a segment as current TCP state at TIME_WAIT. However, in the body of the function definition, it simply goes to "drop" before generating RST or RST/ACK towards the unicast source. Is the behavior correct because the followed codes (from line 2228 to line 3261) would never be reached! Best regards, blue ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
TIME_WAIT state check in in_pcblookup_local()
Hi, All: I have a doubt in in_pcblookup_local() and in6_pcblookup_local() functions in in_pcb.c/in6_pcb.c in FreeBSD-6.1RELEASE. In v4 version (that is, in_pcblookup_local), the inp would be checked to see if the prospective port is used in TCP TIME_WAIT state. If so, it will call tcp_twrecycleable() to see if recycling is possible. However, I noticed that in v6 version (that is, in6_pcblookup_local) would not do such examination. In my opinion, the check should be removed since the connection is still alive in TIME_WAIT state and the port number should be considered unavailable. Best regards, blue ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
FreeBSD-6.1 modification about tcp_input fast recovery
Hi, all:
In FreeBSD-6.1, line 1878 - 1894 in tcp input() have been newly added
like below
if (tp->sack_enable && IN_FASTRECOVERY(tp)) {
int awnd;
/*
* Compute the amount of data in flight first.
* We can inject new data into the pipe iff
* we have less than 1/2 the original window's
* worth of data in flight.
*/
awnd = (tp->snd_nxt - tp->snd_fack) +
tp->sackhint.sack_bytes_rexmit;
if (awnd < tp->snd_ssthresh) {
tp->snd_cwnd += tp->t_maxseg;
if (tp->snd_cwnd > tp->snd_ssthresh)
tp->snd_cwnd = tp->snd_ssthresh;
}
} else
tp->snd_cwnd += tp->t_maxseg;
I am wondering why not just increase congestion window size by 1 when
receiving duplicated ACK when doing fast recover? I digged into RFC 3782
(NeReno) and RFC 3517 (SACK based loss recovery) and could not find
anything related to the modification. Could not we just follow RFC 3782
and simply increment congestion window size by one?
Best regards,
blue
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
[FreeBSD-6.1Release]About the removal of route cache in PCB
Hi, all: I am wondering why the FreeBSD-6.1 version removes the route cache in PCB (struct inpcbin in_pcb.h)? Does the removal do anything good? Or its existence would have potential problems? 'Cause in my opinion, the removal would only produce extra time when emitting a packet since the routing table lookup is unavoidable. So there's must be a good reason for the change. Best regards, blue ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Does mpd (multi-link PPP daemon) support IPv6?
Hi, all: I want to know whether mpd (multi-link PPP daemon) could possibly support IPv6. When I want to establish a PPTP connection with a PPTP server running mpd, could I use IPv6CP instead of IPv4CP to set up the PPP? If it supports, how could I configure the related parameters in the configuration files? I could only find the ipcp syntax. Best regards, blue ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
[FreeBSD-6.1 6.2] Race condition could happen while two thread close socket?
Dear all: When looking into the soclose() in uipc_socket.c, I thought of one possible situation. If thread A called soclose() first, and then execute sorele() then sofree(). However, in sofree() (defined in uipc_socket.c), the socket mutex and accept mutex is unlocked first before releasing socket send buffer. While thread A is dealing with the send buffer releasing, another thread, thread B, jumped in. It also calls soclose(), and then sorele(). Following will be a catastrophe: sorele() will examine the socket's reference count ((so)->so_count), then panic occurs since the count value equals zero! Is there any reasonable explanation? Thanks. BR, Yi-Wen ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
